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The  NATO  Science  and  Technology  Organization 


Science  &  Technology  (S&T)  in  the  NATO  context  is  defined  as  the  selective  and  rigorous  generation  and  application  of 
state-of-the-art,  validated  knowledge  for  defence  and  security  purposes.  S&T  activities  embrace  scientific  research, 
technology  development,  transition,  application  and  field-testing,  experimentation  and  a  range  of  related  scientific 
activities  that  include  systems  engineering,  operational  research  and  analysis,  synthesis,  integration  and  validation  of 
knowledge  derived  through  the  scientific  method. 

In  NATO,  S&T  is  addressed  using  different  business  models,  namely  a  collaborative  business  model  where  NATO 
provides  a  forum  where  NATO  Nations  and  partner  Nations  elect  to  use  their  national  resources  to  define,  conduct  and 
promote  cooperative  research  and  information  exchange,  and  secondly  an  in-house  delivery  business  model  where  S&T 
activities  are  conducted  in  a  NATO  dedicated  executive  body,  having  its  own  personnel,  capabilities  and  infrastructure. 

The  mission  of  the  NATO  Science  &  Technology  Organization  (STO)  is  to  help  position  the  Nations’  and  NATO’s  S&T 
investments  as  a  strategic  enabler  of  the  knowledge  and  technology  advantage  for  the  defence  and  security  posture  of 
NATO  Nations  and  partner  Nations,  by  conducting  and  promoting  S&T  activities  that  augment  and  leverage  the 
capabilities  and  programmes  of  the  Alliance,  of  the  NATO  Nations  and  the  partner  Nations,  in  support  of  NATO’s 
objectives,  and  contributing  to  NATO’s  ability  to  enable  and  influence  security  and  defence  related  capability 
development  and  threat  mitigation  in  NATO  Nations  and  partner  Nations,  in  accordance  with  NATO  policies. 


The  total  spectrum  of  this  collaborative  effort  is  addressed  by  six  Technical  Panels  who  manage  a  wide  range  of 
scientific  research  activities,  a  Group  specialising  in  modelling  and  simulation,  plus  a  Committee  dedicated  to 
supporting  the  information  management  needs  of  the  organization. 
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1ST  Information  Systems  Technology  Panel 

NMSG  NATO  Modelling  and  Simulation  Group 
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SET  Sensors  and  Electronics  Technology  Panel 


These  Panels  and  Group  are  the  power-house  of  the  collaborative  model  and  are  made  up  of  national  representatives  as 
well  as  recognised  world-class  scientists,  engineers  and  information  specialists.  In  addition  to  providing  critical 
technical  oversight,  they  also  provide  a  communication  link  to  military  users  and  other  NATO  bodies. 


The  scientific  and  technological  work  is  carried  out  by  Technical  Teams,  created  under  one  or  more  of  these  eight 
bodies,  for  specific  research  activities  which  have  a  defined  duration.  These  research  activities  can  take  a  variety  of 
forms,  including  Task  Groups,  Workshops,  Symposia,  Specialists’  Meetings,  Lecture  Series  and  Technical  Courses. 


The  content  of  this  publication  has  been  reproduced  directly  from  material  supplied  by  STO  or  the  authors. 
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Urban  Combat  Advanced  Training 
Technology  Architecture 
(STO-TR-MSG-098) 

Executive  Summary 

The  focus  of  the  MSG-098  “Urban  Combat  Advanced  Training  Technology  (UCATT)  Architecture”  Task 
Group  (TG)  was  on  the  maintenance  and  improvement  of  the  previously  developed  functional  architecture 
and  the  identification  and  prioritisation  of  a  standard  set  of  interfaces  that  enable  interoperability  of  live 
training  components  without  inhibiting  future  research  and  enhancements. 

Perhaps  uniquely  within  NMSG  the  UCATT  Architecture  TG  from  the  outset  drew  its  members  from  active 
duty  military,  government  and  industry.  UCATT  has  developed  to  become  a  focal  point  of  knowledge  and 
information  exchange  on  live  simulation  within  NATO  and  PfP.  The  continuation  of  the  UCATT  activities 
within  MSG-140  “UCATT  Live  Simulation  Standards  (LSS)”  secures  not  only  a  vehicle  for  continued  work 
on  standardisation,  but  also  one  to  embed  and  support  the  goals  already  achieved. 

MSG-098  established  very  close  liaison  with  MSG-099  UCATT  Standards  TG.  MSG-098  and  MSG-099 
together  form  the  UCATT  Task  Group  whose  members  represent  the  majority  of  the  S1SO  UCATT  PDG. 
In  conclusion  the  work  of  the  UCATT  TG  to  date  has  provided  NATO  with  a  usable  SISO  standard  for  a 
laser  engagement  interface.  Datasets  for  other  interfaces  to  be  standardised  have  been  identified  and 
described  in  detail.  The  applicability  of  JC31EDM,  MSDL  and  C-BML  as  potential  standard  candidates  for 
C41-integration  has  been  evaluated. 

The  recommendations  of  the  UCATT  Architecture  TG’s  work  are  outlined  below: 

1)  Involve  new  countries  and  industries  and  re-engage  with  countries  that  have  ceased  earlier  active 
involvement  in  the  group. 

2)  Increase  the  “marketing”  activities  to  create  more  awareness  of  the  UCATT  standard  for  live 
simulation  systems  within  the  User  community. 

3)  Reactivate  the  relationship  between  UCATT  TG  and  the  Simulation  Training  and  Operations  Group. 

4)  Establish  liaison  between  the  UCATT  community  and  the  NATO  and  SISO  efforts  enhancing  the 
JC3IEDM,  C-BML  and  MSDL  standards. 

5)  Merge  the  standardisation  and  architectural  activities  together  into  the  follow-up  Task  Group. 

6)  Continuation  of  the  SISO  membership  funding  for  government  members  of  MSG-140. 

7)  Consider  the  translation  of  the  currently  used  functional  architecture  into  the  NATO  Architectural 
Framework  (NAF)  if  applicable  and  useful. 

These  recommendations  have  been  recognised  by  STO  and  that  the  work  of  UCATT  should  continue  for 
four  main  reasons: 

•  To  continue  the  standardisation  effort; 

•  To  form  the  basis  of  SISO  PSGs  necessary  for  the  maintenance  and  availability  of  interface 
standards; 
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•  To  acknowledge  the  applicability  of  the  UCATT  work  is  beyond  just  Urban  training  systems  and 
applies  to  live  simulation  systems  and  Combat  Training  Centres  in  general;  and 

•  To  accommodate  the  increased  international  interest  in  the  interoperability  opportunities  UCATT 
can  provide  and  invite  other  nations  and  participants. 
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Architecture  de  technologie  avancee  pour 
Pentrainement  au  combat  urbain 

(STO-TR-MSG-098) 

Synthese 

Le  groupe  de  travail  (TG)  MSG-098  «  Architecture  de  technologie  avancee  pour  rentrainement  au  combat 
urbain  (UCATT)  »  s’est  focalise  sur  le  maintien  et  l’amelioration  de  l’architecture  fonctionnelle  precedemment 
developpee  et  sur  1’ identification  et  la  hierarchisation  d’un  ensemble  standard  d’interfaces  qui  permettent 
F  interoperability  des  composants  d’entrainement  en  conditions  reelles  sans  freiner  les  recherches  et 
ameliorations  futures. 

Des  le  depart,  le  TG  MSG-098  a  recrute  ses  membres  au  sein  du  personnel  militaire  en  service  actif, 
des  gouvemements  et  de  l’industrie,  ce  qui  est  peut-etre  unique  au  sein  du  NMSG.  L’UCATT  s’est 
developpee  au  point  de  devenir  le  carrefour  des  connaissances  et  de  l’echange  d’ informations  sur 
la  simulation  en  conditions  reelles  au  sein  de  l’OTAN  et  du  PpP.  La  poursuite  des  activites  UCATT  au  sein 
du  MSG-140  «  Normes  de  simulation  en  conditions  reelles  (LSS)  »  est  non  seulement  l’assurance  de  la 
continuity  des  travaux  de  normalisation,  mais  egalement  le  moyen  d’integrer  et  soutenir  les  buts  deja  atteints. 

Le  MSG-098  a  etabli  une  liaison  tres  etroite  avec  le  TG  MSG-099  «  Normes  UCATT  ».  Le  MSG-098  et  le 
MSG-099  forment  ensemble  le  groupe  de  travail  UCATT,  dont  les  membres  represented  la  majority  du 
groupe  de  developpement  de  produit  (PDG)  UCATT  S1SO.  En  conclusion,  le  travail  du  TG  UCATT  a  foumi 
jusqu’a  present  a  l’OTAN  une  norme  S1SO  utilisable  pour  une  interface  d’ engagement  laser.  Les  ensembles 
de  donnees  destines  aux  autres  interfaces  a  normaliser  ont  ete  identifies  et  decrits  en  detail.  L’ applicability 
des  normes  JC31EDM,  MSDL  et  C-BML  pour  l’integration  C41  a  ete  evaluee. 

Les  recommandations  du  TG  sur  1’ architecture  UCATT  sont  indiquees  ci-dessous  : 

1)  Impliquer  de  nouveaux  pays  et  secteurs  economiques  et  reimpliquer  les  pays  qui  ont  cesse  leur 
implication  active  dans  le  groupe. 

2)  Augmenter  les  activites  de  « marketing »  pour  faire  connaitre  la  norme  UCATT  destinee  aux 
systemes  de  simulation  en  conditions  reelles  au  sein  de  la  communaute  des  utilisateurs. 

3)  Reactiver  les  relations  entre  le  TG  UCATT  et  le  Groupe  de  simulation  pour  rentrainement  et  les 
operations. 

4)  Etablir  une  liaison  entre  la  communaute  UCATT  et  l’OTAN  d’une  part,  et  les  travaux  de  la  S1SO 
ameliorant  les  normes  JC31EDM,  C-BML  et  MSDL  d’autre  part. 

5)  Fusionner  les  activites  de  normalisation  et  d’ architecture  au  sein  du  groupe  de  travail  de  suivi. 

6)  Poursuivre  le  fmancement  de  l’adhesion  a  la  S1SO  des  membres  gouvemementaux  du  MSG-140. 

7)  Envisager  la  traduction  de  l’architecture  fonctionnelle  actuellement  utilisee  au  sein  du  cadre 
d’ architecture  de  POT  AN  (NAF)  s’il  y  a  lieu. 

La  STO  a  pris  note  de  ces  recommandations  et  le  travail  de  l’UCATT  devrait  se  poursuivre  dans  quatre 
directions  principals  : 

•  Continuer  les  travaux  de  normalisation  ; 
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•  Former  la  base  de  groupes  d’assistance  technique  des  produits  (PSG)  de  la  S1SO,  veillant  a  la 
maintenance  et  la  disponibilite  des  normes  d’ interface  ; 

•  Reconnaitre  que  les  travaux  UCATT  depassent  le  champ  des  systemes  d’entrainement  urbain  et 
s’appliquent  aux  systemes  de  simulation  en  conditions  reelles  et  aux  centres  d’entrainement  au 
combat  en  general ;  et 

•  Tenir  compte  de  l’interet  international  accru  porte  aux  opportunites  d’interoperabilite  que  l’UCATT 
peut  offrir  et  inviter  d’autres  pays  et  participants. 
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1.1  INTRODUCTION 

Ground  based  warfare  in  an  urban  context  is  perhaps  the  most  deadly  and  complex  type  that  tends  to 
neutralise  much  of  the  technical  superiority  of  modem  armies.  As  such  preparedness  for  operations  in  such 
an  enviromnent  is  vital  for  success.  Investments  in  the  first  generation  of  modem  combat  training  centres 
(with  instmmentation  for  data  collection  and  analysis)  with  urban  training  facilities  began  in  the  1990s. 
These  capabilities  are  generally  bespoke  simulation  designs  to  national  requirements  not  lending  themselves 
easily  to  support  training  events  for  contemporary  coalition  style  operations  as  they  have  limited  ability  to 
achieve  standardisation  and  interoperability.  The  NATO  structure  and  objectives  make  NATO  a  suitable 
organisation  to  seek  to  harmonise  training  requirements  and  move  toward  common  technical  architecture  and 
standards  for  the  next  generation  facilities.  The  NATO  Modelling  and  Simulation  action  /  Master  Plan 
(MSMP)  cites  the  need  for  common  open  standards  and  technical  frameworks  to  promote  the  interoperability 
and  reuse  of  models  and  simulations  across  the  Alliance.  Included  in  this  is  the  need  for  a  common  technical 
framework  to  support  Live  instrumented  training  among  members  of  the  Alliance. 


1.2  BACKGROUND 

Two  NATO  studies  are  the  genesis  of  the  UCATT  work: 

1)  The  NATO  Research  and  Technology  Organisation  (RTO)  1999  Technical  Report,  Land  Operations 
in  the  Year  2020  (L02020);  and 

2)  The  2003  Urban  Operations  in  the  Year  2020  (U02020)  report.  L02020,  in  particular  (as  have  other 
studies)  concluded  that  NATO  forces  would  likely  have  to  conduct  future  operations  in  urban  areas. 

In  response  and  in  support  of  the  MSMP,  a  Team  of  Experts  from  NATO  NAAG  completed  in  2002  a 
feasibility  study  and  concluded  that  a  number  of  potential  interoperability  areas  were  worthy  of  further 
investigation.  As  a  result  the  Urban  Combat  Advanced  Training  Technology  (UCATT)  Task  Group  (TG) 
was  established  within  the  NATO  Modelling  and  Simulation  Group  (NMSG).  Perhaps  uniquely  from  the 
outset  UCATT  drew  members  from  both  government  and  industry  bodies.  UCATT  has  become  the  NATO 
focal  point  for  Urban  training  technology  and  data  exchange  requirements  for  live  training  in  the  land 
domain.  It  is  well  regarded  among  the  military  community  and  industry  as  the  driving  force  within  the  live 
domain. 

1.2.1  UCATT-1 

In  2003  as  MSG-032/TG-023,  UCATT  (later  known  as  UCATT-1)  was  tasked  to  exchange  and  assess 
information  on  Urban  facilities  and  training/simulation  systems  with  a  view  toward  establishing  (then) 
best  practice  and  consider  the  issues  of  interoperability,  architecture  and  interfaces  to  promote 
and  enable  interoperability.  A  Technical  Report  was  delivered  (RTO-TR-MSG-032)  and  a  website 
(http://www.fibuamoutsite.info1)  created  which  was  maintained  by  the  NATO  Urban  Operations  TG. 
The  UCATT-1  report  became  more  or  less  the  guideline  for  urban  combat  training  facilities  design. 

1.2.2  UCATT-2 

In  2007  as  MSG-063/TG-040,  UCATT-2  was  tasked  to  continue  the  work  of  UCATT  and  also  to  undertake 
an  international  interoperability  demonstration  to  show  the  potential  benefit  of  interoperability  standards  and 
commence  a  process  of  defining  standards  data  exchange  and  communication  and  audio  and  visual  effects. 


1  This  website  is  now  closed  and  about  to  be  re-launched  under  a  new  URL  by  the  NATO  Urban  Operations  TG. 
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In  addition  to  delivering  a  Technical  Report  (STO-TR-MSG-063),  a  successful  technical  demonstration  was 
held  at  the  Mamehuizen  training  facility  in  the  Netherlands  in  2011  during  which  a  proof-of-concept  was 
presented  showing  how  systems  from  multiple  manufacturers  might  be  integrated  into  a  single  training 
event. 

1.2.3  UCATT-3 

The  availability  and  subsequent  use  of  a  set  of  standards  would  generate  benefit  if  adopted.  For  the  military 
community  these  include  having  interoperability  across  nations  and  suppliers  to  enable  multinational 
exercises  with  a  nations  own  equipment  or  choice  of  location  leading  to  better  training.  For  the  acquisition 
community,  it  opens  up  the  market  and  provides  tools  to  aide  specification  and  reduce  integration  costs. 
For  industry,  it  offers  the  potential  for  a  more  open  and  potentially  more  frequent  sales  opportunity. 

Therefore  following  the  work  of  MSG-063,  in  201 1  two  UCATT  TGs  were  constituted  to  undertake  the  next 
phase  of  work:  MSG-098  UCATT  Architecture  Task  Group  (referred  to  as  the  AG)  and  MSG-099  Standards 
Task  Group  (referred  to  as  the  SG).  During  this  third  period  of  UCATT,  both  Task  Groups  have  operated  in 
close  concert  with  joint  meetings  to  aid  communication  and  understanding.  This  report  is  that  of  MSG-098, 
the  Architecture  Task  Group.  It  documents  the  task  to  review  and  update  the  generic  functional  architecture 
developed  under  UCATT-2.  Scenarios  were  developed  to  derive  data  exchange  requirements  for  interfaces. 
Selected  data  exchange  requirements  were  issued  to  the  Standards  Task  Group  (MSG-099)  for  development 
into  standards. 

The  first  truly  tangible  output  (the  UCATT  Standard  Interface  for  Laser  Engagement,  to  be  published  by  the 
Simulation  Interoperability  Standards  Organization  (SISO))  is  in  development  as  a  joint  MSG-098/MSG-099 
activity.  A  UCATT  Product  Development  Group  (PDG)  was  chartered  by  SISO  in  November  2013  and  is 
lead  from  MSG-098. 

The  UCATT-3  TGs  MSG-098  and  MSG-099  are  succeeded  by  MSG- 140,  UCATT  Live  Simulation 
Standards  (LSS).  The  different  groups  which  have  been  part  of  the  UCATT  activity  throughout  the  years  are 
depicted  in  Figure  1-1. 


2002  2003  2007  2011  2013  2015 


Figure  1-1:  Composition  of  the  UCATT  Activity. 
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1.3  ILLUSTRATION  OF  THE  NEED  FOR  UCATT  BY  CONTEMPORARY 
EXAMPLE  SITUATIONS 

One  of  the  tasks  performed  by  the  AG  was  the  validation  of  the  Use  Cases  as  the  UCATT-1  TG  formulated 
them.  Those  Use  Cases  have  formed  the  basis  of  UCATT  standardisation  efforts  ever  since,  but  need 
validation  periodically.  It  was  considered  best  to  validate  them  by  comparing  them  to  current  multinational 
exercising  needs  and  system  interconnection  efforts.  The  conclusion  of  the  AG  was,  and  is,  that  the  Use 
Cases  formulated  are  still  valid.  In  the  sections  below,  that  conclusion  is  justified  by  describing  a  few  recent 
or  current-day  example  situations  that  depict  the  need  for  interoperability  standards  for  live  simulation 
systems. 


1.3.1  RNLA:  Connection  of  NLD  Mobile  Combat  Training  Centre  to  DEU  CTC 
GefiibZH  Altmark 

For  many  years  the  Royal  Netherlands  Army  has  conducted  exercises  in  Germany,  either  alone  or  in 
conjunction  with  German  forces.  There  is  a  contract  in  place  for  the  use  of  the  German  CTC, 
GefechtsubungsZentrum  Heer  (GefiibZH)  Altmark,  which  arranges  the  use  of  the  instrumented  training 
area  by  Dutch  forces  at  least  twice  a  year. 

For  most  interfaces  however,  both  CTCs  are  not  interoperable.  Considerable  efforts  and  investments  have 
been  made  in  the  past  to  reach  some  form  of  workable  interoperability.  Full  interoperability,  for  all 
interfaces,  has  not  been  achieved. 

Apart  from  the  optical  laser  interface  for  DFWES,  using  the  OSAG-2  Basic  laser  coding  (which  is  a 
downgrade  for  MCTC),  the  MCTC-GefubZH  connection  does  not  make  use  of  standards.  Interoperability  is 
achieved  by  middleware,  which  acts  as  a  translator  between  EXCONs.  Because  of  that,  MCTC  still  needs  to 
be  deployed  fully,  including  the  portable  base  stations,  for  players  to  interact  with  EXCON  and  vice  versa. 
That  means  in  that  case  the  German  CTC  has  a  double  set  of  base  stations,  one  set  each  for  every  nation. 
This  is  a  very  inefficient  solution,  which  can  be  solved  by  the  use  of  standards  on  a  component  level,  instead 
of  a  translator  on  a  system  level  (see  Figure  1-2). 


Without  interface 
standards 


With  UCATT  interface 
standards 


Figure  1-2:  Interoperability  Without  and  With  UCATT  Interface  Standards. 
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The  current  solution  is  highly  undesirable  from  a  logistical  and  efficiency  point  of  view  even  though  it 
works.  It  should  be  noted  that  it  is  based  purely  on  a  stove-pipe  connection  which  does  not  work  in  any  other 
situation,  using  any  other  system.  The  use  of  the  UCATT  standard  would  allow  the  RNLA  to  deploy  only  its 
MCTC  warehouse(s)  and  make  use  of  the  GefiibZH  Altmark  EXCON  and  AAR  facilities.  At  the  same  time, 
the  MCTC  EXCON  and  AAR  facilities  can  then  be  used  elsewhere  to  support  an  exercise  parallel  to  the  one 
in  GefiibZH  Altmark. 

1.3.2  RNLA:  Integration  of  Forces  on  a  Tactical  Level  Within  NATO  and  EU 

The  current  economic  climate  has  forced  most  (if  not  all)  European  and  NATO  forces  to  work  together  more 
closely  to  address  gaps  in  both  capabilities  and  quantity  of  troops.  Even  though  cooperation  between 
armed  forces  is  not  new,  the  intensity  and  the  level  on  which  it  occurs  is  changing.  Also  outside  combined 
forces  initiatives  like  the  NATO  Response  Force  (NRF)  and  the  EU  Battle  Group,  MOUs  (Memorandum  of 
Understanding)  have  been  signed  on  a  country-to-country  basis.  The  integration  of  forces  is  going  much 
further  than  it  used  to  be  and  to  a  lower  level  than  before.  Examples  of  this,  from  a  NLD  Army  perspective, 
are  the  following: 

•  Integration  of  11  (NLD)  Airmobile  Brigade  (AASLT)  “7  December”  into  the  German  Division 
Schnelle  Krafte. 

•  Integration  of  43(NLD)  Mechanised  Brigade  into  l(DEU)  Panzcrdivision. 

•  Integration  of  one  German  Tank  battalion  into  43(NLD)  Mechanised  Brigade. 

•  Planned  integration  of  1 3(NLD)  Motorised  Brigade  with  French  forces. 

•  The  BENELUX  cooperation  pact  between  The  Netherlands,  Belgium  and  Luxembourg. 

Because  of  this  deep  integration,  these  units  will  train  and  exercise  together  on  a  regular  basis.  Even  before 
integration  these  units  were  used  to  conduct  their  exercises  in  the  most  effective  manner,  by  using  their  live 
simulation  equipment.  To  keep  enabling  these  units  to  use  their  live  simulation  equipment  as  an  integrated 
unit,  their  respective  systems  will  have  to  interoperate.  To  avoid  having  to  build  costly  stove-pipe 
connections  for  each  and  every  system-on-system  connection,  the  use  of  interface  standards  is  the  most 
recommended  and  viable  option,  if  not  the  only  one. 

1.3.3  The  Power  of  Interoperability:  The  NOBLE  LEDGER  Case 

If  there  is  one  case  that  shows  what  the  UCATT  standard  can  achieve,  it  is  the  NATO  Response  Force 
(NRF)  exercise  NOBLE  LEDGER,  held  in  the  south  of  Norway  in  2014.  Goal  of  the  exercise  was  to  certify 
1(GE/NL)  Corps  as  HQ  Land  Component  Command  (LCC)  for  NRF-16.  Secondary  objectives  were  the 
integration  of  multinational  artillery  assets  into  the  Multination  Artillery  Battalion,  certification  of  the  Royal 
Netherlands  Airforce  C-130  capability  and  finally  to  increase  the  cohesion  within  the  Netherlands  led  IRF 
Brigade. 

This  use  case  will  focus  on  the  tactical  exercise  of  the  IRE  Brigade,  which  was  executed  in  the  vicinity  of  the 
Norwegian  training  area  of  Rena.  In  total  5  manoeuvre  battalions  and  1  reconnaissance  squadron  took  part  in 
the  exercise,  led  by  1  l(NLD)  Air  Assault  Brigade  HQ.  Figure  1-3  shows  the  order  of  battle  for  the  one-week 
exercise  in  which  mechanised,  air  assault  and  airborne  operations  were  executed.  OPFOR  consisted  of  one 
infantry  and  one  mechanised  infantry  battalion,  led  by  the  Norwegian  HQ  North. 
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Figure  1-3:  Order  of  Battle  of  the  IRF  Brigade  During  EX  NOBLE  LEDGER. 


The  simulation  component  in  general  consisted  of  4  different  (sub-)  systems: 

•  The  NOR  NACMTC  system,  static; 

•  The  NLD  MCTC  system,  fully  mobile; 

•  DNK  vehicle  DFWES  equipment;  and 

•  DEU  AGDUS  DFWES  equipment. 

In  Annex  B  several  interoperability  issues  are  described,  taking  the  UCATT  functional  architecture  as 
reference.  It  has  to  be  said  that  3  out  of  4  systems  were  from  the  same  manufacturer.  Even  though  this 
implies  proprietary  standards  and  protocols,  this  exercise  still  shows  what  interoperability  between  live 
simulations  systems,  UCATT’s  ultimate  goal,  can  bring  to  tactical  exercises. 

NOBEE  LEDGER  was  a  unique  exercise  from  a  live  simulation  point  of  view.  Never  before  had  4  systems 
interconnected  to  execute  a  Brigade+  level  exercise.  The  last  time  so  many  different  systems  interconnected 
was  during  the  2010  UCATT  proof-of-concept  demonstration  in  Mamehuizen  (NLD).  Unlike  the  UCATT 
demonstration,  which  was  purpose-built  and  took  place  in  a  laboratory  setting,  NOBLE  LEDGER  was  an 
actual  tactical  exercise  with  much  more  players  (2000+),  little  preparation  time  and  more  interfaces  were 
used  here.  In  total,  interoperability  was  achieved  on  6  out  of  1 1  functional  interfaces,  where  7  would  have 
been  likely  possible.  In  the  end,  a  completely  new  CTC  was  built  out  of  4  separate  ones  in  just  a  couple  of 
days  and  with  very  little  financial  investments.  This  shows  what  can  be  achieved  between  systems  from 
different  manufacturers  once  the  UCATT  family  of  standards  is  in  place.  In  this  case  a  second  manufacturer 
already  was  able  to  take  part  in  this  exercise  using  OSAG  2.0,  the  candidate  for  the  future  UCATT  Laser 
Engagement  standard. 

1.3.4  British  Army:  Integrating  a  Cubic  Deployable  Tactical  Engagement  Simulation 
(TES)  Combat  Training  Centre  (CTC)  with  the  US  Joint  Military  Training 
Centre  (JMTC),  Germany 

In  2012  it  was  directed  that  the  British  Army  Training  Unit  Suffield  (BATUS)  that  is  based  in  Alberta 
Canada  shall  conduct  the  first  exercise  of  the  2013  season  at  the  US  Joint  Military  Readiness  Centre  (JMRC) 
at  Grafenwohr  (for  live  fire)  and  the  US  Joint  Military  Training  Centre  (JMTC)  Hohenfels  (for  TESEX) 
range  complex  and  the  manoeuvre  area  lying  between  them.  The  TESEX  phase  ran  May/June  2013. 
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A  military  requirement  was  that  the  quality  of  the  training  support,  objective  evidence  gathered  and  after 
action  review  provided  to  the  audience  was  to  be  maintained  compared  with  that  which  would  have  been 
provided  at  BATUS;  this  was  to  be  BATUS  delivered  training  to  BATUS  standards. 

Amongst  other  issues,  this  demanded  that  a  similar  level  of  training  instrumentation,  support  and  data 
analysis  was  to  be  provided  to  that  which  would  have  been  delivered  by  the  in-place  AWES  (Cubic  supply) 
and  DFWES  (Saab  supply)  that  constitutes  the  installed  TES  capability  at  BATUS. 

In  the  absence  of  instrumentation  and  systems  interoperability  (the  ultimate  UCATT  goal  that  one  day  might 
enable  troop  to  turn  up,  turn  on  and  go),  it  was  necessary  to  investigate  potential  solutions  to  provide  the 
required  engagement,  communication,  tracking  and  analysis.  Amongst  the  options  considered,  cost  effective 
solutions  included: 

1)  Use  by  the  Battle  Group  (BG)  and  OPFOR  of  the  full  capability  of  the  installed  US  TES  equipment 
by  adaptation  where  necessary  and  the  full  US  Collective  Training  Establishment  (CTE) 
infrastructure,  accepting  performance  shortfalls  such  as  reduced  User  experience,  system  fidelity  and 
system  limitations  for  data  collection  and  thus  subsequent  analysis. 

2)  Use  by  the  BG  and  OPFOR  of  a  mix  fleet  of  UK  TES  equipment  for  vehicles  and  US  TES  equipment 
for  dismounts  together  with  the  full  US  CTE  infrastructure,  accepting  increased  cost  and  risk  of  the 
plan  from  the  need  to  engineer  vehicle  TES  interfaces  to  improve  some  aspects  of  system 
performance  and  fidelity. 

3)  Use  by  the  BG  of  a  temporarily  established  UK  instrumentation  capability  (UK  vehicle  and  man- 
worn  equipment,  a  UK  radio  and  data  collection  capability  plus  EXCON  and  supporting  functions) 
but  utilising  some  elements  of  the  US  CTE  infrastructure  (e.g.,  towers  and  communication  bearers), 
and  with: 

a)  OPFOR  provided  by  a  UK  force  employing  UK  equipment  using  additional  UK  supplied 
equipment;  or 

b)  OPFOR  provided  by  a  US  force  employing  US  equipment  using  additional  UK  supplied 
equipment  modified  as  required  to  fit  US  systems. 

The  selected  method  was  3b  as  it  achieved,  in  addition  to  other  benefits,  the  necessary  instrumentation 
system  performance,  fidelity  and  data  collection  requirements,  enabled  simplified  connection  to  other 
systems  (such  as  that  to  provide  distributed  situational  awareness  for  O/Cs  and  a  Synthetic  Wrap  injection) 
plus  the  same  experience  for  the  trainees  to  that  offered  at  BATUS. 

To  deliver  this  choice,  whilst  the  delivery  of  the  DFWES  (Saab)  element  was  straightforward,  it  was  not 
quite  so  for  the  AWES  (Cubic)  element.  To  achieve  a  suitable  outcome,  considerable  bespoke  and  specific 
engineering  effort  (including  systems  and  component  design,  test  and  installation,  integrations  with  extant 
infrastructure  and  system  level  testing)  with  the  associated  project  and  commercial  management  activity 
across  multiple  contracts  was  expended.  In  addition  significant  inter-agency  liaison  for  permissions,  access 
and  approval  to  operate  was  needed.  Each  attracted  costs,  and  whilst  some  costs  would  not  re-occur  if  this 
was  to  be  undertaken  again,  those  reoccurring  costs,  is  a  significant  disincentive  to  a  repeat  event. 

Native  system  or  component  interoperability  that  UCATT  seeks  to  enable  would  not  eliminate  all  the 
required  effort  and  resource  consumption  to  deliver  such  instrumentation  to  support  training,  but  would 
reduce  the  scope  of  the  task,  the  associated  risk  to  the  plan  and  the  time  needed  to  enable  the  event. 
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1.3.5  British  Army:  Integrating  a  Saab  Deployable  Tactical  Engagement  Simulation 
Combat  Training  Centre  with  the  Cubic  Static  Combat  Training  Centre  on 
Salisbury  Plain,  England 

1.3. 5.1  Introduction 

Between  July  and  August  2011,  the  UK  MoD  conducted  exercise  PASHTUN  DAWN  15  (PD  15)  on 
Salisbury  Plain  as  part  of  pre-deployment  training  for  units  due  to  rotate  into  Afghanistan.  What  is  described 
below  are  some  observations  of  the  interim  arrangement  for  the  instrumentation  of  that  exercise  that  was 
established  to  cater  for  the  circumstance  where  the  numbers  of  live  entities  exceeded  the  in-place  capacity. 
This  arrangement  was  a  stopgap  measure  whilst  work  to  enhance  the  installed  capability  on  Salisbury  Plain 
was  in  process.  However,  it  does  demonstrate  the  work  required  to  attempt  to  provide  interoperability 
between  two  bespoke  Combat  Training  Centres  (CTCs)  of  different  design  (and  in  this  instance  each  from  a 
different  manufacturer  and  being  of  different  generations).  Some  of  the  limitations  and  failings  encountered 
justify  the  long  term  goal  of  UCATT. 

1.3.5.2  Background  and  Requirement 

To  support  Mission  Specific  Training  (MST)  in  preparation  for  operations  in  Afghanistan  the  PASHTUN 
DAWN  series  of  exercises  held  on  Salisbury  Plain  consisted  of  two  BG  scale  events  with  OPFOR  and 
civilian  population  supported  by  a  full  range  of  instrumented  weapons  and  vehicles  to  inform  detailed 
training  mission  analysis  and  After  Action  Review  (AAR).  The  instrumentation  requirement  for  PD  15 
differed  from  normal  UK  instrumented  training  in  scale  (numbers)  and  use  of  operation-specific  vehicles. 
MST  exercises  were  designed  to  enable  two  BG  to  train,  one  on  the  East  and  one  on  the  West  side  of  the 
training  area  with  the  audience  augmented  with  ‘cross-Plain’  brigade  troops  and  logistics  support  controlled 
by  a  notional  task-force  command.  Each  BG  operated  essentially  in  isolation  from  the  other  but  there  was 
movement  of  enemy,  civilian  and  brigade  troops  across  the  entire  area  of  operations. 

Effective  instrumentation  of  this  exercise  type  was  not  initially  possible  with  the  installed  capability  on 
Salisbury  Plain  unless  very  significant  exercise  compromises  were  accepted  mainly,  but  not  entirely,  due  to 
the  entity  count.  Work  was  in-hand  to  address  shortfalls,  but  in  the  interim  and  for  PD  15  alone,  funding  was 
provided  to  undertake  work  to  deliver  an  essential  minimum  capability  which  was  to  consist  of  a  meld  of 
CTCs  systems  to  constitute  a  single  larger  capability. 

1.3.5.3  The  Systems  Employed 

Two  systems  were  employed  to  create  the  required  capability;  the  in-place  UK  Salisbury  Plain  CTC  and  a 
deployable  CTC  normally  employed  by  the  UK  in  Kenya  (the  Temporary  Tactical  Engagement  Simulation 
In  Kenya  (TTES1K).  The  Salisbury  Plain  CTC  itself  consists  of  two  Tactical  Engagement  Simulation  (TES) 
systems:  AWES,  which  is  supplied  and  supported  by  Cubic  Defence  Applications  and  provides  man-worn, 
small  arms,  vehicle  tracking  instrumentation,  data  gathering,  comms  plus  EXCON  and  AAR  facilities, 
which  is  used  in  conjunction  with  the  DFWES  appended  precision  fire  weapon  equipment  supplied  by  Saab 
Training  Systems  (STS).  This  CTC  was  scaled  for  single  BG  level  training  events  (and  is  similarly  available 
in  BATUS,  Canada).  For  this  Use  Case  it  is  appropriate  to  consider  AWES  the  main  element  of  the  Salisbury 
Plain  CTC. 

In  2011  the  AWES  capability  lacked  formal  generic  vehicle  instrumentation  and  could  not  support  the 
numbers  of  entities  intended  for  MST  exercises.  Thus  AWES  was  supplemented  for  PD  15  by  the  TTES1K 
system  that  was  normally  to  be  found  supporting  the  British  Army  Training  Unit  in  Kenya  (BATUK)  as  a 
Deployable  CTC.  This  was  possible  as  the  BATUK  training  schedule  allowed  time  for  TTES1K  to  be 
shipped  to  the  UK  for  use  on  Salisbury  Plain  for  PD  15.  TTES1K  was  (and  remains)  a  Deployable  TES 
system  operated  by  STS  as  a  managed  service  for  the  UK  MOD  and  provides  a  full  CTC  capability 
optimised  for  training  of  light  role  forces  up  to  BG  level. 
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1.3. 5.4  Integration 

The  early  intent  was  to  operate  TTES1K  and  AWES  as  segregated  systems  with  manual  interaction/ 
intervention.  But  this  approach  did  not  meet  the  Army’s  training  desire  so  additional  funding  was  required  to 
support  a  technical  integration  activity  to  address  this.  So  Saab  and  Cubic  were  tasked  to  conduct 
integrations  for  the  MoD  with  further  advice  provided  by  QinetiQ.  The  approach  taken  for  technical 
integration  was  to  minimise  changes  to  the  AWES  system  due  to  the  older  technology  used  (which  woidd 
have  added  technical  and  timescale  risk).  So  changes  were  mostly  made  to  the  TTES1K  system  along  with 
middleware  integration  using  the  QinetiQ  operated  Architecture  Independent  Modelling  Environment 
(AIME)  toolkit.  The  main  technical  issues  identified  that  required  to  be  addressed  were  simulation  and 
EXCON  interoperability.  In  particular,  five  areas  identified  were: 

•  Laser  simulation  -  At  the  time  of  the  exercise  AWES  used  a  UK-bespoke  version  of  MILES  and  the 
TTESIK  system  a  UK-bespoke  version  of  OSAG  1 .  These  codes  are  non-interoperable  but  do  use 
the  same  physical  transmission  layer,  namely  near  infra-red,  Class  1  lasers  with  matched  detectors. 
As  a  result  it  was  necessary  to  instigate  a  re-programme  activity  to  enable  TTESIK  laser  transmitters 
to  operate  on  MILES. 

•  Real-time  tracking  integration  -  The  Army  required  the  ability  to  display  and  track  all  training 
activity  in  a  single  system,  regardless  of  whether  those  tracked  entities  were  using  TTESIK  or  AWES 
instrumentation.  The  information  exchanged  had  to  be  consistent  between  the  systems  as  it  was  also 
going  into  other  systems  that  rely  on  TES  instrumentation  such  as  ISTAR  representations. 

•  Simulation  support  tools  in  the  field  -  TTESIK  has  a  field-able  exercise  monitoring  tool  that  is  a 
component  part  of  the  TTESIK  system.  AWES  uses  a  similar  system  called  AWES  Distributed 
Situational  Awareness  (ADSA).  Both  these  systems  were  to  be  available  to  observer/controllers. 
Exercise  control  on  the  ground  was  enabled  using  control  or  ‘god’  guns  that  had  to  interface  with  the 
AWES  man-wam  system,  the  TTESIK  man-worn  and  all  vehicles  whether  fitted  with  Cubic  or  Saab 
supplied  equipment. 

•  ISTAR  -  The  primary  Intelligence,  Surveillance,  Target  Acquisition  and  Reconnaissance  (ISTAR) 
simulation  on  PD15  was  provided  by  QinetiQ’s  Synthetic  Wrap  team,  using  VBS2  and  AIME. 
Unmanned  Aerial  Vehicle  (UAV)  products  from  this  simulation  were  used  to  brief  the  training 
audience,  so  a  consistent  visualisation  of  events  on  the  ground  was  key  to  training  immersion. 

•  AAR  -  Each  BG  received  an  AAR  from  their  respective  training  system,  TTESIK  or  AWES. 
But  cross-system  visibility  was  needed  to  provide  Higher  Control  (HICON)  context  and  to  brief 
cross-Plain  activity. 

1.3.5.5  Initial  Configuration 

The  initial  configuration  for  the  combined  system  was  as  shown  in  Figure  1-4  below. 
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Figure  1-4:  System  Configuration. 


This  configuration  had  an  exercise  management  burden  as  there  was  no  automation  of  ORBAT  information 
or  player  IDs.  Thus  Cubic  and  Saab  staff  were  required  to  carefully  manage  EXCON  information  through 
version  control  and  communication  between  each  other.  The  configuration  only  provided  real-time  data 
transfer  as  the  integration  method  used  by  AIME,  AWES  and  TTESIK  for  data  transfer  was  DIS  and  DIS  is 
a  real-time  simulation  protocol  not  designed  to  enable  transmission  of  historic  or  ‘latent’  data  that  can  be 
generated  by  TES  equipment  when  fielded  systems  drop  out  of  real-time  connection  with  EXCON. 

The  arrangement  did  not  provide  interoperable  operation  of  IED  simulators  as  each  system  employed  IED 
simulators  with  proprietary  RF  transmission  to  operate  and  there  was  no  time  or  resource  available  to 
generate  a  technical  solution.  Similarly  it  was  not  possible  to  address  the  question  of  TTESIK  equipped 
players  being  tethered  to  vehicles  instrumented  by  AWES  they  mounted,  nor  was  any  Urban  instrumentation 
integration  attempted.  This  resulted  in  some  orchestration  of  the  exercise  to  mitigate  these  limitations. 

1.3.5.6  Issues  Encountered 

The  headline  issues  encountered  were: 

•  Whilst  the  work  needed  to  achieve  laser  interoperability  was  understood  and  laser  code 
interoperability  was  achieved  through  using  MILES,  detailed  investigation  revealed  the  performance 
difference  between  the  lasers  and  detectors  of  the  two  companies  can  create  an  ‘unfair  fight’ 
situation  with  respect  to  probability  of  hit  and  effective  range  when  mixed  (i.e.  a  Cubic  Small  Arms 
Transmitter  vs  a  Saab  detector  set,  and  vice-versa). 

•  It  was  swiftly  apparent  that  despite  being  a  known  issue  concerning  player  IDs,  TTESIK  fitted 
weapons  were  not  achieving  hits  on  AWES  players  due  to  poor  initial  ID  management;  it  prevented 
correct  operation  until  fixed. 

•  As  initially  employed  the  physical  differences  in  man-worn  systems  of  the  two  companies  provided 
an  easy  way  for  the  training  audience  to  single  out  hidden  OPFOR  amongst  civilians  as  the  AWES 
version  was  identifiably  different  from  the  TTESIK  one  -  even  at  long  range.  This  resulted  in 
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employment  changes  and  the  plan  to  have  AWES  equipped  OPFOR  operating  amongst  the  TTES1K 
equipped  western  BG  was  dropped. 

•  RF  spectrum  and  interference,  especially  operating  in  the  licence-free  spectrum  and  shows  that 
unhindered  use  of  that  spectrum  in  new  locations  cannot  be  taken  for  granted. 

•  There  were  incidents  where  indirect  fires  created  in  AWES  created  unintended  consequences  in 
TTES1K.  For  example,  on  calling  for  a  mortar  strike  on  a  platoon  location,  H1CON  specified  that 
2  to  3  individuals  should  be  wounded  or  killed.  The  AWES  fires  desk  has  the  ability  to  tightly 
control  the  effect  size  of  simulated  fires  to  achieve  this  effect.  Elowever,  these  control  variables  are 
lost  in  the  translation  to  D1S  and  back  into  TTES1K.  When  the  fire  mission  landed  on  the  TTES1K 
equipped  platoon,  it  was  with  the  full  potential  of  TTESIK’s  area  weapons  model.  The  entire 
platoon  was  killed,  requiring  a  reset  in  order  to  continue  with  the  exercise  plan.  In  another  incident, 
the  AWES  fires  desk  created  a  smoke  round  mission  that  would  stimulate  AWES  vests  with 
artillery  warnings  but  not  cause  any  casualties.  This  kind  of  control  is  useful  to  the  exercise  staff 
when  they  want  to  create  a  trigger  event  for  a  serial.  Again,  on  transmission  to  TTESIK,  there  was  a 
misinterpretation  and  the  TTESIK  system  replaced  smoke  rounds  with  81  mm  high-explosive 
mortar  rounds.  Again,  this  resulted  in  unintended  consequences.  For  this  exercise  the  sub-optimal 
solution  was  to  revert  to  separate  fire  mission  control,  coordinated  by  the  AWES  fires  desk  as  a 
single  point  of  contact  for  the  military  exercise  controller.  With  indirect  fires  effectively  being 
managed  manually  between  east  and  west  parts  of  the  training  area,  the  resulting  system  was  loosely 
integrated  on  the  ground.  The  automated  interface  points  remaining  were: 

•  TTESIK  laser  interoperability  with  DFWES  equipped  vehicles,  e.g.,  combat  logistics  patrols 
and  brigade  operations; 

•  Common  EXCON  view  of  entity  locations,  states  and  hit  events;  and 

•  Common  deployed  observer/controller  view  of  entities  via  ADSA  and  TTESIK  O/C  terminals. 

1.3.5.7  Lessons 

As  a  result  of  this  event  lessons  were  identified  across  a  range  of  areas  including  the  management  of  the 
remaining  PASHTUN  DAWN  series,  future  acquisitions  and  for  the  employment  of  deployable  systems. 
These  included  the  need  for  interoperability  with  exercise  management  systems  and  integration  with 
Operational  Command  Information  Systems  to  spectrum  management,  operational  de-confliction  and  the 
need  for  caution  when  operating  in  the  licence-free  spectrum.  In  addition  it  was  noted  that  the  entity  update 
rates  were  not  always  fast  enough  for  effective  stimulation  of  ISTAR  serials  and  this  should  be  addressed. 

Of  particular  relevance  to  this  Report  are  that: 

•  On  one  hand,  proprietary  interfaces  were  a  costly  hindrance  yet  on  the  other,  solutions  can  be 
developed  by  industry  to  reduce  these  impacts.  This  effort  showed  there  are  significant  benefits  of 
having  the  ability  to  re-programme  laser  devices  to  support  multiple  code  sets. 

•  This  work  proved  there  was  more  to  interoperability  for  small  arms  than  laser  code  and  message 
formats,  for  example,  once  laser  encoding  issues  are  removed  simulated  weapon  performance  is 
influenced  by  other  factors  such  as  laser  emitter  beam  propagation,  detector  sensitivity  and  firing 
vector  dynamics  over  the  time  of  the  laser  emission. 

•  The  DIS  interface  as  implemented  was  not  found  to  be  suitable  for  passing  indirect  fire  missions 
(and  other  missions  such  chemical/biological/radiological  contamination)  between  systems  and  a 
more  suitable  protocol  is  needed  to  pass  such  between  TES  systems  in  a  consistent  and  predictable 
way. 

•  It  was  observed  that  AAR  effectiveness  had  the  potential  to  be  degraded  due  to  missing  data  caused 
by  players  not  in  real-time  connectivity  with  EXCON.  The  solution  to  this  in  the  future  will  be  to 
adapt  or  adopt  a  simulation  protocol  to  enable  absolute  time-stamping  of  reports. 


1  -10 


STO-TR-MSG-098 


OVERVIEW 


1.3. 5.8  Summary 

The  combining  of  AWES  and  TTES1K  in  the  summer  of  2011  provided  a  stopgap  capability  pending 
delivery  of  enhancements  to  the  CTE  on  Salisbury  Plain  to  support  bespoke  exercises  for  UK  forces 
preparing  to  deploy  to  Afghanistan.  It  is  difficult  to  predict  what  would  have  been  achieved  without  the 
integration  effort  but  there  would  have  been  little  or  no  interoperability  of  EXCON  systems,  leading  to 
completely  separate  BG  exercises  and  AARs.  It  is  possible  there  may  have  been  some  DFWES  and  TTES1K 
interoperability  as  both  these  components  are  designed  by  Saab.  There  would  be  no  MILES  integration  of 
small  arms  and  man-worn  systems.  But  this  experience  has  reinforced  the  UK  requirement  for  native 
interoperability  within  design  to  meet  UK  training  needs  let  alone  the  requirement  to  train  with  allies.  A  step 
taken  toward  standardised  laser  codes  and  backward  compatibility  to  MILES  has  been  taken  and  since  2014 
all  Saab  products  in  service  with  the  UK  are  OSAG  2  UCATT  compliant.  But  the  potential  issue  of  an  un¬ 
fair  fight  due  to  equipment  performance  of  a  mixed-supplier  fleet  difference  remains. 


1.4  WORKING  METHODOLOGY 

This  section  describes  the  process  followed  by  the  AG. 

1.4.1  Staged  Approach 

The  starting  point  for  the  AG  was  the  UCATT-2  report  delivered  by  MSG-063  which  recommended  work  to 
elaborate  on  user  requirements  for  urban  combat  training  systems  in  the  live  domain  and  to  draft  a  first  series 
of  standards  to  enable  interoperability  among  different  combat  training  systems. 

The  AG  was  able  to  make  rapid  progress,  because  many  of  its  members  had  been  involved  in  the 
predecessors  L02020,  MSG-032  UCATT  (also  known  as  UCATT-1)  and  MSG-063  UCATT-2. 

The  first  activity  was  to  produce  a  roadmap,  consisting  of  subjects  to  investigate  and  products  to  deliver 
during  the  mandated  timeframe  of  the  AG.  These  activities  were  mapped  on  the  AG  meeting  schedule, 
which  consisted  of  3  meetings  a  year.  This  schedule  is  depicted  in  Figure  1-5. 


Figure  1-5:  UCATT  Meeting  Schedule. 
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During  the  subsequent  meetings  the  roadmap  was  checked  and  updated  if  required  and  proved  to  be  a 
valuable  tool  for  work  management  to  ensure  progress  towards  the  end  result. 

In  collaboration  with  the  SG  it  was  decided  to  first  start  working  on  the  external  interface  that  enables 
engagements  between  live  dynamic  objects.  The  AG  therefore  delivered  a  description  of  the  data  that  has  to 
be  transferred  (a  superset  of  data  elements)  for  the  different  types  of  engagements. 

The  SG  was  responsible  for  the  specification  of  the  physical  implementation  of  this  interface.  They  decided 
not  to  start  from  scratch,  but  to  choose  an  existing  code  set  as  baseline,  taking  the  drafted  superset  of 
engagement  data  into  account.  In  order  to  perform  this  selection  in  a  transparent  and  structured  way,  the  AG 
and  SG  adopted  a  set  of  voting  procedures,  based  on  “Robert’s  Rules”.  For  a  definition  of  Robert’s  Rules  in 
the  UCATT  context  see  Annex  K  (UCATT’s  Rules  of  Business).  These  rules  were  applied  to  select  the 
base  code  set  for  the  first  UCATT  engagement  interface  standard.  The  members  of  both  AG  and  SG  were 
involved  in  this  voting  process.  As  outcome  the  OSAG-2  code  set  was  chosen  as  baseline. 

After  specifying  the  dataset  for  the  engagement  interface,  the  AG  continued  to  specify  the  datasets  for  the 
other  external  interfaces.  These  external  interfaces  were  identified  in  the  UCATT  Functional  Architecture 
(UCATT  FA),  as  designed  by  the  UCATT-1  and  UCATT-2  TGs.  During  this  process,  the  interfaces  and  the 
architecture  were  analysed  in  more  detail.  This  led  to  some  minor  changes  to  the  Functional  Architecture 
(FA)  and  the  identification  of  a  new  external  interface.  The  resulting  FA  and  definitions  of  all  external 
interfaces  are  described  in  Chapter  2. 

1.4.2  Use  of  Existing  Standards 

The  objective  of  UCATT  is  to  identify  and  specify  interfaces  to  enable  interoperability  among  different 
combat  training  systems.  It  has  been  recognised  that  within  NATO  and  SISO  a  number  of  (research)  projects 
have  been  executed,  or  even  are  still  progressing,  that  aim  for  interoperability  among  systems  and  have 
produced  standards.  Examples  are  DIS,  HLA,  JC31EDM,  MSDL,  C-BML  etc.  Although  initially  many  of 
these  standards  have  been  created  mainly  focussing  on  application  in  the  virtual  and/or  constructive  domain, 
they  can  also  have  value  in  the  live  domain.  Therefore  the  UCATT  AG  was  also  tasked  to  evaluate  the 
applicability  of  existing  and/or  developing  standards  in  the  UCATT  FA.  UCATT  will  seek  to  create  a  new 
standard  only  when  no  other  suitable  standard  is  available. 

The  AG  considered  several  existing  standards  to  assess  their  applicability  for  certain  UCATT  interfaces. 
This  resulted  in  the  identification  of  some  promising  candidates  (see  Chapter  3),  together  with 
recommendations  to  increase  their  functionality  to  meet  certain  UCATT  requirements. 

1.4.3  Interaction  with  NATO  and  Other  Groups 

MSG-098  UCATT  Architecture  TG  was  very  closely  linked  to  MSG-099  UCATT  Standards  TG.  MSG-098 
identified  and  prioritised  candidate  interfaces  for  standardisation  through  the  SISO  process.  MSG-098  was 
also  the  “supplier”  of  the  relevant  Use  Cases  and  the  datasets  for  the  standardisation  process.  Questions  that 
arose  during  the  work  of  MSG-099  were  brought  back  to  MSG-098  and  feedback  given. 

In  order  to  introduce  a  SISO  Standard  a  SISO  Product  Development  Group  was  established,  consisting  of 
members  from  both  AG  and  SG.  This  ensured  both  technical  and  User  aspects  were  addressed.  PDG 
meetings  were  scheduled  within  the  UCATT  meeting  calendar. 

During  UCATT-1  and  UCATT-2  information  about  User  requirements  and  best  practises  was  exchanged 
between  UCATT  and  the  Training  and  Simulation  Working  Group  (TSWG).  During  the  UCATT-3  phase 
this  useful  interaction  was  disrupted  due  to  change  of  personnel  within  UCATT  and  the  transformation  of  the 
TSWG  into  MSG-1 16  Simulation  Training  and  Operations  Group  (STOG). 
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When  applicable,  the  AG  called  upon  the  expertise  of  other  STO  TGs,  especially  those  involved  with 
interoperability  standards  such  as  that  the  work  of  MSG-085  C2S1M  which  led  to  a  briefing  on  MSDL, 
C-BML  and  JC3IEDM  to  assist  AG  work  to  assess  these  as  potential  candidates  for  UCATT  interface 
standards. 

The  Interoperability  User  Community  (IUC)  is  a  SAAB  led  community  of  Users  of  live  simulation 
equipment  manufactured  by  SAAB.  The  purpose  of  which  is  to  achieve  interoperability  between  customers 
and  to  steer  product  development  for  Company  and  User  benefit.  A  number  of  UCATT  TG  members  are 
also  active  within  the  IUC,  and  this  has  facilitated  the  exchange  of  certain  information  including  ammunition 
table  data  and  details  of  the  OSAG  code.  This  has  been  a  key  relationship. 

1.4.4  SISO  Related  Activities 

Even  though  MSG-098  is  a  NATO  NMSG  driven  activity,  its  focus  is  to  define  and  prioritise  interfaces  to  be 
standardised  through  the  SISO  process  as  mandated  by  STO.  As  the  standardisation  process  has  to  be  driven 
by  a  PDG  which  is  formed  by  live  simulation  community  (military,  government  and  industry),  the  members 
of  MSG-098  agreed  to  all  join  SISO  and  to  subscribe  to  the  UCATT  PDG.  The  same  applied  to  the  members 
of  MSG-099.  Members  of  MSG-098  took  the  positions  of  SISO  PDG  Chair  (Cpt  Sander  Cruiming)  and  Vice 
Chair  (Mr.  Staffan  Martinsen). 

For  efficiency,  SISO  PDG  meetings  were  aligned  with  the  UCATT  meetings  and  time  allocated  to  SISO 
activities.  But  much  of  the  development  of  the  SISO  Standard  documents  was  done  between  the  UCATT 
meetings.  The  SISO  portion  of  the  meetings  was  then  used  to  conduct  formal  elections  and  balloting. 
This  method  of  integrating  SISO  work  into  UCATT  work  has  proved  to  work  very  effectively  and  should  be 
continued  in  the  future. 

A  problem  that  occurred  was  that  the  flexible  method  of  working  within  the  UCATT  TGs  sometimes 
conflicted  with  the  structured  procedures  of  SISO.  This  delayed  the  progress  a  lot  and  led  to  the  fact,  that  a 
balloted  UCATT  standard  could  not  be  finished  within  the  4-year  period  of  MSG-098.  However,  a  draft 
UCATT  standard  is  delivered  to  be  balloted  by  the  SISO  community. 

1.4.5  Benefit  and  Continued  Involvement  of  Industry,  Government  and  Military 

The  unique  composition  of  the  UCATT  group  with  members  from  government,  military  and  industry  in  the 
spirit  of  an  open  minded  and  cooperative  collaborative  working  method  creates  a  win-win  situation  for  all 
participating  parties.  Governments  and  military  users  benefit  from  the  experiences  and  knowledge  of  their 
respective  counterparts  and  industry  can  give  guidance  on  technological  possibilities  and  feasibility.  In 
exchange,  the  industry  members  get  first-hand  information  on  future  User  requirements  and  on  government 
desired  standards.  The  concept  of  a  mixed  group  has  been  proved  for  over  10  years  and  should  be  kept  for 
the  follow-up  activity. 


1.5  RESULTS  OF  UCATT-3 

The  main  task  of  the  UCATT-3  TGs  was  to  deliver  at  least  one  sub-standard  to  SISO.  The  first  interface 
chosen  to  be  standardised  was  the  laser  engagement  interface.  In  order  to  achieve  that  goal  and  to  enable  the 
SG  to  deliver  the  standard  for  SISO  review,  several  sub-tasks  were  formulated.  Those  sub-tasks  are  listed 
below,  followed  by  the  achieved  results.  Elaborations  of  those  results  can  be  found  elsewhere  in  this  report 
and  in  the  attached  annexes. 

1)  Revise  the  UCATT  Functional  Architecture  as  developed  by  UCATT-2: 

The  AG  revised  the  FA  by  checking  it  against  the  existing  or  plausible  future  use  cases  and  known 
examples  from  practice.  This  was  an  on-going  process  throughout  all  AG  activities,  but  most 
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examples  were  found  in  the  process  of  creating  the  code -sets  listed  in  Annexes  E  through  H. 
By  testing  how  a  certain  practical  example  fitted  in  the  FA,  necessary  adaptations  were  discovered 
and  the  architecture  updated.  The  resulting  changes  made  to  the  FA  can  be  found  in  Section  2. 1 .5. 

2)  Set  requirements  on  the  implementation  of  vulnerability  models: 

Considerable  thought  has  gone  into  this  issue,  where  the  main  question  was  if  vulnerability  models 
and  vulnerability  calculation  itself  woidd  need  to  be  standardised  in  order  to  achieve  interoperability. 
It  was  decided  by  the  group  that  from  a  technical  perspective,  standardisation  of  neither  was 
necessary  to  achieve  technical  interoperability.  From  a  fair-play  perspective  though,  the  issue  is 
different.  If  a  tank  instrumented  by  system  A  fires  at  an  vehicle  instrumented  by  system  B, 
the  outcome  of  that  engagement  should  be  a  reasonable  and  a  logical  one,  even  when  both  systems 
use  different  damage  models  and/or  method  of  calculation.  The  AG  decided  to  standardise  the  input 
(ammunition  code)  and  the  output  (damage  status)  and  consider  the  vulnerability  to  be  a  proprietary 
“black  box”.  The  assumption  here  is  that  there  is  not  that  much  difference  in  damage  calculation  that 
would  lead  to  an  imbalanced  fight  and  a  lack  of  fair  play.  In  short:  if  the  input  is  standardised,  it  does 
not  matter  if  system  A  receives  a  35  mm  ammo  code  from  system  B  or  C  because  that  ammo  code 
would  not  differ  from  the  code  received  from  one  of  its  “own”  TES  lasers.  Assuming  the  national 
requirements  of  each  individual  system  already  lead  to  a  logical  and  fair  outcome  when  training  on  a 
national  site,  mixing  systems  would  lead  to  a  similar  logical  and  fair  outcome. 


Figure  1-6:  Concept  of  Vulnerability  Model. 

The  damage  states  were  built  up  in  a  parent-child  structure,  starting  from  the  lowest  common 
denominator  (e.g.,  a  MILES  based  system)  as  a  base  (level  1).  This  ensures  both  legacy  system 
support,  enable  future  growth  and  allow  higher  levels  of  fidelity  if  needed. 

The  ammunition  codes  were  delivered  to  the  S1SO  PDG  as  an  annex  and  reference  document  to  the 
UCATT  laser  engagement  interface  standard  document.  The  agreed  upon  damage  states  can  be 
found  in  Annex  D. 

3)  Revise  Use  Cases  as  formulated  by  the  UCATT-1 ,  including  non-kinetic  effects: 

The  Use  Cases  that  were  formulated  during  UCATT-1  formed  part  of  the  basis  for  the  UCATT 
work  as  to  determine  in  which  situations  interoperability  between  systems  was  deemed  necessary. 
The  Use  Cases  are  described  in  Chapter  2  of  the  UCATT-1  Report: 

•  USE  CASE  0  -  National  Training  on  National  Site; 

•  USE  CASE  1  -  Live  MOUT  Training  Multinational  Force  on  a  National  Site; 

•  USE  CASE  2  -  Use  Other  Nations  Training  Facility  and  Staff; 

•  USE  CASE  3 A  -  Distributed  Combined  Training; 

•  USE  CASE  3B  -  Combined  Training  in  Mission  Area;  and 

•  USE  CASE  4  -  Command  and  Staff  training  for  Engagements  in  Different  Mission  Areas. 
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To  ensure  the  activities  of  UCATT  are  still  valid  and  focussed  in  the  right  direction,  it  is  necessary 
to  revise  and  validate  all  past  results  from  time  to  time.  The  Use  Cases  were  compared  to  the  current 
situation  and  exercise  demands  within  NATO  and  for  each  individual  member  country.  The  Use 
Cases  were  found  to  be  still  valid  by  the  AG  and  no  reasons  were  found  to  change  them. 

4)  Set  requirements  for  direct  engagements  between  dynamic  objects: 

Setting  the  requirements  for  direct  engagements  was  probably  one  the  most  important  tasks  for  the 
AG,  as  they  would  form  the  basis  for  the  UCATT  interface  standard  for  laser  engagement.  This  is 
also  reflected  in  the  prioritisation  of  interfaces  (see  Section  2.4). 

To  formulate  the  requirements  for  direct  engagements  the  AG  took  on  the  task  of  identifying  the 
information  and  parameters  that  needed  to  be  sent  through  that  interface,  enabling  all  thinkable 
current  and  future  types  of  direct  engagement.  Direct  engagements  are  engagements  directly  from 
player  A  to  player  B.  The  most  obvious  direct  engagement  is  probably  a  soldier  firing  at  another 
soldier,  but  also  non-kinetic  engagements  (e.g.,  medical  treatment)  were  considered. 

The  training  needs  of  the  contributing  nations  were  and  are  the  starting  point  for  the  functional 
requirements  made.  One  by  one,  each  type  of  engagement  was  broken  down  into  tables  of 
parameters,  including  the  required  accuracy,  unit  or  (geographical)  system.  These  identified  required 
parameters  where  subsequently  handed  over  to  the  SG,  who  used  them  as  requirements  for  choosing 
the  UCATT  optical  interface  standard.  More  on  that  subject  can  be  found  in  the  MSG-099  UCATT 
Standards  technical  report.  The  data  sets  can  be  found  in  Annex  E. 

5)  Set  requirements  for  the  reporting  of  the  status  of  a  dynamic  object: 

The  requirements  for  reporting  the  status  of  a  dynamic  object  were  identified  by  analysing  the 
(type  of)  information  that  a  dynamic  object  needs  to  communicate,  so  that  other  elements,  such  as 
other  players  and  EXCON,  can  observe  the  status  or  status  change.  This  information  is  important  for 
both  online  monitoring  and  for  AAR  purposes.  The  AG  successfully  completed  this  task  and  the 
results  can  be  found  in  Annex  F. 

6)  Set  requirements  for  AWES  (Area  Weapon  Effect  Systems)  implementation: 

Setting  the  requirements  for  the  AWES  function,  or  non-direct  engagements,  was  very  similar  to  the 
work  done  on  direct  engagements,  with  some  specific  differences  unique  to  artillery,  CBRN  and 
engineering  functionalities.  The  results  of  this  task  can  be  found  in  Annex  E. 

7)  Set  requirements  for  the  integration  of  C41  systems: 

The  integration  of  C41  systems  in  training  systems  is  currently  a  “hot  topic”  and  is  pursued  by  many 
countries  and  manufacturers.  This  originates  from  the  fact  that  military  units  rely  more  and  more  on 
systems  like  BMS  (Battlefield  Management  System)  for  their  situational  awareness  and  tactical 
command.  Training  systems  need  to  capture  C41  system  data  for  monitoring  and  AAR  purposes. 
On  the  other  hand,  C41  systems  need  to  be  fed  with  training  system  data.  This  covers  a  usage  of 
EXCON  not  identified  before:  cyber  warfare  injections.  It  also  inevitably  gives  EXCON  HICON 
(Higher  Control)  functionality,  since  those  injections  influence  the  tactical  battle.  Before,  it  was 
considered  that  EXCON  monitored  and  influenced  the  technical  status  of  the  simulation  system, 
but  only  monitored  and  logged  the  tactical  exercise.  The  E7  interface  allows  influencing  the  battle 
by  spoofing,  giving  misinformation  or  shutting  down  the  C4I  systems  units  rely  on  so  heavily. 
Even  though  currently  there  are  no  known  examples  of  cyber  warfare  being  used  in  instrumented 
brigade  level  exercises  or  lower,  the  UCATT  AG  predicts  this  will  happen  in  the  future.  This  is  a 
good  example  of  how  UCATT  seeks  to  develop  requirements  and  a  standard  that  allow  future 
growth. 

Results  of  the  completion  of  this  task  can  be  found  in  Section  3.2.3. 
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8)  Set  requirements  for  EXCON  capabilities  and  interconnections: 

The  system-to-system  interface  was  one  of  the  interfaces  that  made  the  UCATT-2  interoperability 
demonstration  in  Mamehuizen  possible.  It  is  still  the  most  commonly  used  interface  today  when 
trying  to  make  limited  interoperability  possible.  Furthermore,  this  interface  is  used  to  connect  other 
systems  like  virtual  or  constructive  trainers  and  can  be  useful  for  LVC  or  “synthetic  wrapping” 
purposes. 

During  its  mandate  UCATT  has  discussed  possible  candidates  for  this  system-to-system  interface, 
like  HLA,  D1S  or  TENA. 

9)  Elaborate  contemporary  example  situations  in  relation  to  virtual  and  constructive  simulations: 

In  its  TAP  and  TOR  UCATT  identified  that  interoperability  of  live  simulation  with  the  virtual  and 
constructive  domain  is  very  important.  It  was  also  recognised  that  already  many  efforts  are  being 
undertaken  by  others  to  set  requirements  and  develop  standards.  Therefore  further  investigation  was 
considered  outside  of  the  UCATT  scope.  However,  to  show  the  relation  between  the  UCATT 
standard  and  LVC  applications,  a  few  current  and  relevant  examples  were  described  and  added  to 
this  report  and  can  be  found  in  Annex  1. 

10)  Set  requirements  for  pairing  and  association  of  dynamic  objects: 

Analysis  of  interactions  in  a  training  system  showed  that  weapons  and  dynamic  objects  need  to 
exchange  information,  other  than  engagements.  For  example,  it  can  be  important  to  know  who 
operates  a  piece  of  equipment  or  weapon,  or  if  a  player  is  allowed  to  or  capable  to  operate  that 
equipment  or  weapon.  Also,  damages  to  one  object  can  result  in  damage  to  other  objects,  based  on 
temporary  relations  or  circumstances.  The  results  can  be  found  in  Sections  3. 3.4.3  and  3. 3.4.4. 

11)  Set  requirements  for  the  interaction  between  the  simulation  system  and  real-life  (weapon)  platforms: 

Since  UCATT  can  only  specify  or  propose  standards  for  simulation  systems  and  not  for  real-life 
platforms,  this  interface  is  considered  a  very  difficult  one.  It  is  possible  to  set  requirements  for  which 
type  of  information  is  accessible  to  the  system,  e.g.,  GPS  positioning  data  or  Laser  Range  Finder 
information.  For  actual  standardisation  however,  an  agreement  with  all  or  most  platform 
manufacturers  would  have  to  be  made.  At  this  point  this  is  considered  to  be  an  unreachable  goal  and 
would  require  too  much  effort,  mainly  because  it  is  highly  unlikely  a  3rd  party  would  get  access  to  a 
vehicles’  (e.g.,  main  battle  tank  or  infantry  fighting  vehicle)  internal  information  network. 

During  MSG-098  the  requirements  for  this  interface  have  not  been  considered  and  may  be  a  task  of 
MSG-140  UCATT  LSS. 

12)  Set  requirements  for  the  configuration  of  the  live  simulation  systems: 

UCATT  defined  an  external  interface  to  initialise  the  simulation  system  before  starting  the  exercise. 
During  this  timeframe  MSG-098  has  focused  on  the  ORBAT  data,  since  the  issues  here  are  most 
pressing  for  contemporary  joint  and  combined  exercises:  currently  there  is  no  interoperability  and  a 
lot  of  this  data  still  has  to  be  entered  into  the  system  manually,  which  takes  a  lot  of  time  and  effort. 

To  exchange  ORBAT  information,  UCATT  turned  towards  another  (S1SO)  standard  that  already 
contains  a  lot  of  ORBAT  data:  the  Military  Scenario  Definition  Language  or  MSDL.  Although  the 
work  is  not  complete,  after  scanning  the  standard  the  AG  decided  that  MSDL  is  a  good  candidate  for 
this  interface.  For  other  types  of  data  the  suitability  of  MSDL  still  has  to  be  researched,  which  has 
been  transferred  as  an  activity  to  MSG-140  UCATT  LSS. 

1 3)  Check  APP-6(C)  for  missing  symbols  in  relation  to  live  (urban)  training: 

Most  EXCON  facilities  use  either  3D  models  or  unit  symbols  in  their  graphical  user  interfaces. 
To  standardise  that  symbology  it  was  deemed  logical  to  use  NATO  symbols,  as  prescribed  in  NATO 
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STANAG  APP-6.  This  STANAG  was  written  however  from  an  operational  perspective,  not  a 
training  one.  The  military  subgroup  within  UCATT  has  therefore  performed  a  scan  of  APP-6(C)  to 
see  if  there  were  any  symbols  missing  for  either  Urban  Operations  or  live  simulated  training. 
The  results  of  that  scan  can  be  found  in  Annex  J.  During  the  coming  MSG-140  UCATT  LSS 
timeframe  another  scan  will  be  made  to  see  if  in  the  (D)  version  of  APP-6  some  or  all  of  these  issues 
have  been  resolved.  The  remaining  omissions  will  be  handed  over  to  NATO  as  an  advice  to  be 
included  in  the  next  version  of  APP-6. 

14)  Investigate  existing  standards  as  candidates  for  each  interface: 

The  UCATT  Architecture  Task  Group  does  not  stand  on  its  own  and  is  part  of  a  larger  SISO  and 
NATO  community  that  strives  for  standardisation.  Some  of  the  interfaces  in  the  UCATT  functional 
architecture  connect  to  systems  of  which  another  MSG  of  SISO  PDG  has  already  made  efforts  to 
achieve  interoperability.  The  C4I  community  is  a  good  example  of  this,  where  considerable  efforts 
have  been  made  to  enable  C4  systems  to  interact  with  each  other.  It  was  therefore  considered  very 
likely  that  those  standards  already  facilitate  the  UCATT  needs  to  a  large  extent  and  were  viable 
candidates  for  UCATT  interfaces. 

During  the  UCATT-3  timeframe  members  of  UCATT-3  have  actively  promoted  the  UCATT  standards, 
like  for  example  Levels  of  Fidelity,  NMSG  symposia,  SISO  seminars  and  the  Deutsche  Gesellschaft  flir 
Wehrtechnik  Training  and  Simulation  Forum. 


1.6  RECOMMENDATIONS 

The  recommendations  of  the  MSG-098  work  are  outlined  below: 

1)  Involve  new  countries  and  industries  and  re-engage  with  countries  that  have  ceased  earlier  active 
involvement  in  the  Group. 

Rationale:  Multinational  training  is  increasingly  important  for  the  future  with  the  trend  for  coalition 
operations.  Technical  interoperability  of  training  systems,  equipment  and  devices  can  assist  in 
improving  training  effectiveness  bringing  with  it  operational  benefit.  A  wider  base  of  contributing 
nations  and  industrial  entities  with  UCATT  potentially  leads  to  earlier  and  more  widespread 
adoption. 

2)  Increase  the  “marketing”  activities  to  create  more  awareness  of  the  UCATT  standard  for  live 
simulation  systems  within  the  User  community. 

Rationale:  To  create  interest  for  further  national  involvement  and  adoption  of  UCATT  standards  by 
nations  and  industry  awareness  must  be  increased.  This  could  be  achieved  by  articles  in  magazines, 
papers,  conference  presentations,  speeches,  etc. 

3)  Reactivate  the  relationship  between  UCATT  TG  and  STOG. 

Rationale:  In  order  to  ensure  a  correct  User  perspective  is  held  within  UCATT,  it  is  believed 
necessary  to  establish  and  maintain  a  close  working  or  at  least  an  effective  communication  between 
the  two  bodies. 

4)  Establish  liaison  between  the  UCATT  community  and  the  NATO  and  SISO  efforts  enhancing  the 
JC3IEDM,  C-BML  and  MSDL  standards. 

Rationale:  UCATT  will  seek  to  create  a  new  standard  only  when  no  other  suitable  standard  is 
available.  JC3IEDM  and  C-BML  are  likely  candidates  as  baseline  for  E6  and  E7,  and  MSDL  for 
(a  large  part  of)  Ell.  However,  these  existing  standards  should  also  incorporate  UCATT  specific 
requirements. 
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5)  Merge  the  standardisation  and  architectural  activities  together  into  the  follow-up  Task  Group. 

Rationale:  The  anticipated  benefits  of  the  separation  into  two  different  groups  did  not  materialise. 
Indeed  the  consequential  increased  administrative  overhead  has  proven  disadvantageous. 

6)  Continuation  of  the  SISO  membership  funding  for  government  members  of  MSG- 140. 

Rationale:  Having  established  a  SISO  UCATT  standard,  that  standard  must  be  maintained  by  a 
SISO  Product  Support  Group  (PSG).  It  is  in  NATO’s  interest  to  ensure  a  stable  community  is  in 
place  to  do  that  and  this  can  be  achieved  through  this  recommendation. 

7)  Consider  the  translation  of  the  currently  used  functional  architecture  into  the  NATO  Architectural 
Framework  (NAF)  if  applicable  and  useful. 

Rationale:  This  will  aid  to  verify  the  validity  of  the  architectural  approach  in  relation  to  physical 
implementations. 

These  recommendations  have  been  recognised  by  STO  and  that  the  work  of  UCATT  should  continue  for 
four  main  reasons: 

•  To  continue  the  standardisation  effort. 

•  To  form  the  basis  of  SISO  PSGs  necessary  for  the  maintenance  and  availability  of  approved 
interface  standards. 

•  To  acknowledge  the  applicability  of  the  UCATT  work  is  beyond  just  Urban  training  systems  and 
applies  to  live  simulation  systems  and  Combat  Training  Centres  and  reflect  this  in  the  name  of  the 
follow-up  activity  (UCATT  LSS). 

•  To  accommodate  the  increased  international  interest  in  the  interoperability  opportunities  UCATT 
can  provide  and  invite  other  nations  and  participants  (three  additional  nations  will  contribute  to 
UCATT  LSS). 

The  activity  proposal  was  endorsed  by  the  NMSG  during  the  Business  meeting  in  Oslo,  June  2014  and  was 
approved  by  the  STB  in  September  2014  as  MSG-140  UCATT  Live  Simulation  Standards  (LSS). 

It  was  also  determined  that  the  scope  of  UCATT  has  been  widened  up  from  ‘only’  urban  training  systems  to 
live  simulation  systems  in  general.  This  is  reflected  in  the  name  of  the  follow-up  activity  UCATT  LSS. 

The  TAP  and  TOR  for  UCATT  LSS  have  been  created  during  the  working  period  of  MSG-098  and  can  be 
found  in  Annex  A. 
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2.1  INTRODUCTION  AND  CHANGES  DURING  THE  UCATT-3  PERIOD 

2.1.1  The  Capability  Requirements  Matrix  (CRM) 

It  was  recognised  in  2003  that  doctrine  published  by  individual  NATO/PfP  countries  did  not  support  or 
identify  joint  or  combined  requirements  for  conducting  effective  military  operations  in  an  urbanised 
environment.  Very  few  training  exercises  were  conducted  at  the  joint  or  combined  level  in  an  urban  training 
environment.  Countries  had  different  requirements  for  the  level  of  live  training  conducted  from  squad 
(4-8  personnel)  through  to  Brigade  level. 

As  late  as  2006  urban  training  was  not  mandated  by  many  of  NATO  and  PfP  countries.  The  first  UCATT 
TG,  as  one  of  its  tasks,  sought  to  identify  the  needs  of  the  different  countries’  training  capability  requirements, 
evaluate  those  requirements  and  make  recommendations  on  a  generic  set  of  capability  requirements  for 
urban  operations  training  in  the  Live,  Virtual  and  Constructive  (LVC)  domains.  In  order  to  carry  out  this  task 
a  Requirements  Matrix  Sub-Group  was  established. 

The  purpose  of  the  Capability  Requirements  Matrix  (CRM)  was  to  identify  those  components  needed  to 
support  training  at  all  levels  from  Squad  to  Brigade  across  the  full  spectrum  of  military  operations,  including 
military  aid  to  civil  authorities  and  cooperation  with  other  governmental  departments,  international 
organisations  and  non-governmental  organisations.  Although  it  was  initially  intended  to  include  all  three 
environments  only  the  live  training  environment  was  completed.  The  development  of  the  CRM  and  its 
subsequent  analysis  was  used  to  identify  common  elements,  interoperability  issues  and  where  standards 
could  be  applicable  in  conducting  (urban)  live  training.  These  were  then  addressed  in  a  functional 
architecture  and  interfaces,  through  the  definition  of  a  common  set  of  functional  training  requirements. 

The  capabilities  identified  in  the  CRM  describe  the  requirements  for  a  Combat  Training  Centre  (CTC)  from 
a  user  point  of  view.  In  order  to  derive  from  these  capabilities,  a  generic  set  of  requirements  for  the 
development  of  CTCs,  it  is  necessary  to  have  a  common  understanding  of  the  training  system  from  a  system 
point  of  view.  This  means  that  there  must  be  insight  into  the  functions  of  the  training  system,  how  they  are 
grouped  together  into  components  and  what  types  of  interactions  take  place  between  those  components. 
Only  then  it  is  possible  to  discuss  interoperability  issues  and  compose  the  desired  requirements. 
More  information  and  the  complete  CRM  can  be  found  in  Annex  F  of  the  MSG-032  RTO  Technical  Report. 

In  order  to  gain  this  insight  and  bridge  the  gap  between  the  capabilities  on  one  hand  and  requirements  for  the 
development  of  CTCs  on  the  other  hand,  an  architecture  had  to  be  created  and  agreed  upon. 

2.1.2  The  Functional  Architecture  (FA) 

Formally,  an  architecture  is  “the  organisational  structure  of  a  system  or  component,  their  relationships, 
and  the  principles  and  guidelines  governing  their  design  and  evolution  over  time”  (IEEE  610.12).  There  are 
many  different  types  of  architecture,  but  two  main  categories  are  the  functional  and  design  architectures: 

•  A  Functional  Architecture  (FA)  is  “an  arrangement  of  functions  and  their  sub-functions  and 
interfaces  (internal  and  external)  that  defines  the  execution  sequencing,  conditions  for  control  or 
data  flow,  and  the  performance  requirements  to  satisfy  the  requirements  baseline”. 

•  A  Design  Architecture  (DA)  is  “an  arrangement  of  design  elements  that  provides  the  design  solution 
for  a  product  or  life  cycle  process  intended  to  satisfy  the  functional  architecture  and  the 
requirements  baseline”  (IEEE  1220). 
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It  was  the  purpose  of  UCATT  to  set  requirements  for  interoperability,  which  is  the  ability  of  systems  to 
exchange  data,  information  and  services  to  enable  them  to  operate  effectively  together.  At  the  same  time, 
industry  should  have  the  freedom  to  propose  and  implement  the  most  cost-effective  solutions  they  can 
devise,  as  long  as  they  satisfy  the  interoperability  requirements.  So,  the  UCATT  main  focus  is  on  system 
interfaces.  In  this  context,  an  interface  describes  the  characteristics  at  a  common  boundary  or  connection 
between  systems  or  components. 

To  identify  and  define  the  system  boundaries  and  interactions  with  other  systems  (external  interfaces),  it  is 
sufficient  to  create  and  analyse  the  FA  of  a  CTC.  This  FA  must  be  representative  enough  to  cover  all  Use 
Cases  defined  earlier  and  the  requirements  from  the  CRM,  while  not  touching  specific  design  or 
implementation  issues.  The  FA  captures  what  the  system  can  or  might  do,  not  how  it  does  or  should  do  it 
(e.g.  the  requirement,  not  the  implementation  such  as  communication  which  might  actually  be  by  wireless 
transmission  or  through  a  cable).  The  UCATT  FA  is  illustrated  in  Figure  2-1. 


UCATT  Functional  Architecture 


Figure  2-1:  The  UCATT  Revised  Functional  Architecture. 


Another  subject  of  particular  interest  is  the  level  of  detail  of  the  FA.  Too  few  details  will  result  in  insufficient 
possibilities  for  interoperability,  while  too  many  details  will  result  in  losing  oversight  and  identifying 
irrelevant  interfaces  for  interoperability. 


2,1.3  Internal  and  External  Interfaces 

In  the  case  of  the  FA,  an  interface  exists  where  data  is  exchanged  between  functions  that  reside  in  the 
architecture.  While  the  complete  FA  describes  and  identifies  all  functions  and  interfaces  that  can  be  found  in 
a  CTC,  it  does  not  definitively  identify  the  interfaces  that  need  to  be  standardised  to  establish  interoperability. 
In  order  to  do  that,  a  difference  was  made  between  internal  and  external  interfaces. 
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Internal  interfaces  are  defined  as  those  that  handle  data  communication  that  only  take  place  in  the  system 
itself  or  a  designated  sub-system,  whereas  external  interfaces  communicate  to  either  the  outside  of  the 
system  or  to  a  system  component  that  can  be  replaced  by  a  non-native  component  (e.g.,  a  Personnel 
Detection  Device  or  Small  Arms  Transmitter  from  a  different  vendor).  The  internal  interfaces  where 
considered  proprietary  and  out  of  scope  for  standardisation,  since  they  were  not  mandatory  for  achieving 
interoperability. 

By  identifying  the  external  interfaces,  it  is  made  explicit  what  interfaces  need  to  be  standardised  to  achieve 
interoperability.  The  external  interfaces  where  subsequently  give  the  designation  “E”,  followed  by  an 
identifying  number.  From  there  on,  these  “Es”  formed  the  basis  of  all  the  work  done  by  UCATT-3, 
especially  during  the  final  delivery  phase.  A  standard  definition  for  each  interface  can  be  found  in  the 
sections  and  the  annexes  of  this  document. 

2.1.4  Considerations  Regarding  the  Functional  Architecture 

Special  care  has  been  taken  in  the  definition  of  the  architecture  to  allow  for  different  implementations. 
For  example,  an  engagement  between  a  shooter  and  a  target  can  be  modelled  in  two  different  ways: 

•  Distributed  solution:  The  shooter  engages  the  target.  Subsequently,  the  target  senses  this  engagement 
through  its  “sense”  capability  and  activates  its  “determine  effect”  capability.  The  resulting  change  of 
status  is  then  reported. 

•  Centralised  solution:  If  the  “Determine  effect”  capability  does  not  reside  locally  in  a  player  unit,  the 
result  of  engagements  is  determined  centrally  in  the  capability  “Control  dynamic  object  status”. 
The  data  flow  will  then  be:  the  target  senses  an  engagement,  the  local  “Determine  effect”  is  not 
present  or  will  have  no  effect,  the  target  reports  the  characteristics  of  the  engagement,  which  is 
captured  and  through  “Manage  data”  provided  to  “Control  dynamic  object  status”.  Alternatively, 
in  implementations  where  the  players  have  no  sensing  capability  themselves,  but  instead  the  training 
system  detects  engagements,  the  sensing  capability  of  the  training  systems  determines  that  a  player 
is  engaged  and  provides  the  engagement  characteristics  to  the  central  “Control  dynamic  object 
status”  capability.  That  capability  determines  the  effects  of  the  engagement  and  subsequently 
provides  the  results  to  the  target.  The  target  senses  the  command  to  change  its  status,  performs  the 
status  change  and  reports  its  new  status,  so  other  components  of  the  system  are  aware  of  this. 

2.1.5  Changes  to  the  FA  During  the  UCATT-3  Timeframe 

The  UCATT  Functional  Architecture  was  introduced  in  the  UCATT-1  report  (RTO-TR-MSG-032)  and  is 
still  the  basis  for  the  continuing  UCATT  work.  However,  successive  UCATT  Task  Groups  have  identified 
shortcomings  or  improvements.  The  UCATT-2  report  (STO-TR-MSG-063)  identified  the  need  for  two 
additional  external  interfaces  E9  and  E10.  These  interfaces  were  further  investigated  and  detailed  during 
UCATT-3.  This  resulted  also  in  some  adaptations  to  the  FA  and  its  interfaces: 

•  E9  was  redirected  (from  “Report  status”)  to  “Sense”. 

•  The  function  “Fire  control”  was  renamed  to  “Platform  control”. 

•  An  additional  external  interface,  Ell,  was  defined  which  incorporates  part  of  the  original  E8 
interface  and  the  part  of  E9  that  connected  “Manage  data”  and  “Create  data”. 

The  revised  FA  is  depicted  in  Figure  2-1  above.  In  this  figure,  the  red  arrows  represent  the  external  interfaces, 
identified  by  an  E-number.  The  black  arrows  represent  the  internal  interfaces  and  their  specification  is  out  of 
the  scope  of  UCATT  standardisation. 
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2.2  KEY  ELEMENTS  OF  THE  FUNCTIONAL  ARCHITECTURE 

2.2.1  Functional  Components  and  External  Interfaces 

For  practical  purposes,  it  is  useful  to  distinguish  several  functional  components  within  a  UCATT  training 
system.  A  functional  component  is  a  logical  grouping  of  functions  that  are  related  to  each  other  from  a  user’s 
point  of  view.  Although  functional  components  do  have  a  relation  with  physical  components  or  facilities, 
it  is  not  intended  to  influence  the  physical  implementation  or  location  of  a  UCATT  training  system. 
The  breakdown  of  the  training  system  into  functional  components  serves  purely  to  facilitate  in  defining 
interoperability.  In  the  UCATT-1  report  6  main  functional  components  were  distinguished,  3  of  them  are 
extensively  used  in  the  UCATT-3  report:  the  Dynamic  Object  (DO),  Exercise  Control  (EXCON)  and 
Observer/Controller  (O/C). 

The  second  type  of  key  elements  of  the  functional  architecture  are  the  external  interfaces.  UCATT  has 
identified  1 1  external  interfaces  (El  through  Ell),  which  are  described  in  the  subsections  below. 

2.2.2  Dynamic  Object  (DO) 

A  Dynamic  Object  (DO)  is  defined  as  a  live,  virtual  or  constructive  element  in  the  training  environment  that: 

1 )  Has  a  presence  in  the  environment  and  either; 

2)  Has  a  valid  status;  or 

3)  Can  influence  the  status  of  other  DOs  (execute  engagements)  or  possesses  both  of  these 
characteristics. 

Ad  1  -  Presence:  a  DO  can  be  seen,  observed  or  detected  in  the  training  environment.  For  example, 
a  vehicle  can  be  seen  by  the  naked  eye,  observed  in  infra-red,  detected  by  radar  and  be  tracked  by  C41 
systems  and  a  CBRN  area  can  be  detected  with  specific  sensors.  Associated  with  its  presence  is  its  position. 
During  an  exercise  the  position  of  a  DO  can  be  dynamic  (e.g.  a  soldier  can  move  around)  or  static 
(e.g.  a  structure  or  feature  which  stays  on  the  same  position  during  an  exercise). 

Ad  2  -  Status  indicates  the  (level  of)  capabilities  of  a  DO.  It  can  be  very  basic  (such  as  for  example  dead / 
alive  for  human  beings,  or  operationaFdestroyed  for  weapon  systems  and  infrastructure),  or  it  can  be  more 
complex,  distinguishing  between  more  levels  of  degraded  performance.  The  status  of  a  DO  can  be  changed 
during  and  exercise,  either  resulting  from  engagements  from  other  DOs  or  by  (interventions  from)  the 
training  system  for  exercise  effect  or  administration.  Although  it  could  be  required  that  a  certain  DO  has  a 
fixed  status  that  cannot  be  changed  rendering  it  “untouchable”  or  “indestructible”  in  an  exercise.  A  typical 
example  of  such  a  DO  is  an  O/C,  whose  status  cannot  be  changed,  yet  it  can  engage  other  DOs. 

Ad  3  -  Engagement:  A  DO  can  influence  the  status  of  other  DOs.  For  example,  a  soldier  can  fire  an  anti¬ 
tank  weapon  at  a  vehicle  or  at  a  building,  a  wall  could  be  destroyed  and  with  its  debris  it  can  engage  DOs  in 
its  vicinity,  and  a  CBRN  area  can  affect  unprotected  DOs  that  enter  it.  However,  examples  of  DOs  that 
cannot  engage  are  a  pop-up  target  or  an  unarmed  UAV,  which  is  just  a  sensor  platform. 

2.2.3  Exercise  Control  (EXCON) 

EXCON  is  the  capability  to  define  and  (remotely)  monitor  and  control  an  exercise.  Generally  this  is  done 
from  a  central  location.  For  sake  of  simplicity,  in  this  document  it  is  also  assumed  that  EXCON  also  contains 
the  capability  to  analyse  the  results  of  an  exercise  and  provide  feedback  to  the  trainees  (in  an  After  Action 
Review  (AAR)),  and  the  capability  to  monitor  and  control  the  training  system  itself,  necessary  to  support  the 
training  exercise  (System  Control). 
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2.2.4  Observer/Controller  (O/C) 

An  Observer/Controller  (O/C)  is  the  capability  to  monitor,  influence  and  evaluate  an  exercise  by  distributed, 
local  means.  It  is  a  role  in  the  training  area  played  by  exercise  staff.  The  O/C  component  might  seem 
a  logical  part  of  EXCON.  They  share  much  functionality,  but  the  O/C  capability  also  has  some  other 
functionality  that  clearly  distinguishes  it  from  EXCON. 

In  addition,  an  O/C  is  also  a  DO.  The  O/C  is  present  in  the  simulated  battlefield  and  can  engage  other  DOs, 
either  by  directly  changing  their  status  or  by  imitating  engagements  from  a  virtual  actor. 

2.2.5  External  Interface  Descriptions 

The  UCATT  external  interfaces  describe  a  number  of  transactions;  each  type  of  transaction  is  mapped  on 
one  or  more  transportation  methods,  requiring  a  physical  interface. 

2.2.5.1  El  -  DO  Engagement  (Engage  =»  Sense) 

This  interface  represents  an  action  of  one  DO  on  (one  or  more)  other  DOs,  with  the  purpose  to  change  the 
status  of  that  other  DOs.  The  engagement  contains  only  the  characteristics  of  the  action,  not  the  resulting 
status  of  the  affected  DOs,  the  resulting  status  has  to  be  determined  based  on  these  engagement  parameters. 

Examples: 

•  Direct  or  indirect  fire  from  a  shooter  to  a  target; 

•  Explosion  of  a  mine,  possibly  affecting  the  status  of  DOs  in  its  influence  sphere; 

•  Medical  treatment  of  a  medic  on  an  injured  person;  and 

•  Repair  action  by  a  maintenance  engineer  on  a  damaged  vehicle. 

2.2.5.2  E2  -  Training  System  Status  Change  (Control  Training  System  Status  =>  Sense) 

This  interface  controls  the  technical  status  of  a  DO,  enabling  its  functioning  in  the  training  environment. 
Through  this  interface  it  is  possible  that  a  DO  is  initialised,  reset,  calibrated  etc.  It  also  accommodates  the 
distribution  of  an  (altered)  terrain  representation  or  damage  models  for  systems  that  require  this  data  at 
decentralised  nodes,  for  example  in  each  DO  for  determination  of  engagement  effects. 

2.2.5.3  E3  -  DO  Status  Change  (Control  Dynamic  Object  Status  =>  Sense) 

Through  this  interface  the  (simulated)  operational  status  of  a  DO  is  affected  by  other  sources  than 
engagements  by  DOs.  This  interface  implements: 

•  The  direct  change  of  DO  parameters,  such  as  its  operational  status  or  logistic  supplies.  This  can  be  a 
direct  action  of  an  O/C,  for  example  a  reset,  or  the  distribution  of  the  outcome  of  an  engagement  that 
is  centrally  evaluated  (typically  in  EXCON).  This  interface  is  required  for  geo-pairing  systems  and 
for  training  systems  that  centrally  simulate  engagement  areas  such  as  for  example  artillery  areas. 

•  The  distribution  of  certain  engagement  parameters,  so  that  the  proper  audio  and/or  visual  effects  can 
be  triggered  locally  at  the  DO,  even  though  the  engagement  outcomes  are  centrally  determined  and 
provided  to  the  DO  (e.g.,  a  DO  that  is  affected  by  artillery  fire  is  provided  with  the  new  status, 
but  also  with  the  type  of  ammunition  and  distance  of  impact,  so  the  proper  audio  effects  can  be 
generated  by  the  DO). 

•  The  distribution  of  engagement  parameters  to  the  affected  DOs  to  determine  the  outcome  of  the 
engagement  locally  at  the  DO  level.  This  functionality  is  required  when  the  (primary)  triggering  of 
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an  engagement  is  centrally  determined,  but  the  determination  of  the  outcome  is  also  dependent  on 
information  that  is  available  at  the  DO  level  but  not  (e.g.  for  latency  reasons)  in  EXCON.  Examples 
are  virtual  engagement  areas  created  in  EXCON,  such  as  minefields,  fire  support  target  areas  and 
CBRN  areas.  EXCON  can  determine  that  a  DO  is  engaged  by  an  engagement  area,  but  the 
engagement  outcome  also  has  to  take  into  account  local  parameters  such  as  protection  factors 
(e.g.  wearing  armour,  CBRN  mask)  or  attitude  (e.g.  standing  or  prone). 

•  The  distribution  of  the  characteristics  of  engagement  areas  (such  as  fire  support  target  areas, 
minefields  and  CBRN  areas),  so  the  triggering  of  engagements  with  these  areas  and  the  subsequent 
determination  of  the  resulting  outcome  can  be  done  locally  at  the  DO  level. 

2.2.5.4  E4  -  DO  Reporting  (Report  Status  =>  Capture  Data) 

A  dynamic  object  reports  its  (change  of)  status  through  this  interface  to  the  rest  of  the  world.  The  status 
contains  for  example  operational  status,  location,  supplies,  engaging  or  being  engaged,  etc. 

This  interface  exists  in  different  physical  domains,  for  example  the  communication  of  the  status  to: 

•  EXCON  (typically  radio  communication);  and 

•  Players,  including  visual  presentations  (smoke,  lights)  or  sounds  (explosion). 

Remark:  The  interfaces  to  trigger  the  physical  devices  (for  example  pyrotechnics  when  shooting  or  being 
hit)  are  considered  internal  interfaces. 

2.2. 5.5  E5  -  EXCON  Communication  (Use  EXCON  Communication  <=>  Use  EXCON 
Communication) 

This  interface  enables  the  communication  between  training  staff  members  of  different  systems  operating  in 
the  same  exercise.  It  covers: 

•  Voice  radio  communication;  and 

•  Exchange  of  for  example  electronic  notes,  pictures,  and  video. 

2.2.5.6  E6  -  Receive  C4I  Data  (Use  C4I  =>  Capture  Data) 

This  interface  transfers  data  from  C41  systems  to  a  UCATT  training  system.  This  includes  Battlefield 
Management  System  (BMS)  functionality  such  as  a  report  from  a  scout  that  an  enemy  vehicle  has  been 
detected  or  a  graphical  sketch  showing  the  situation.  This  data  can  be  stored  in  the  training  system  for 
analyses  purposes  and  can  be  used  during  AAR. 

2.2. 5.7  E7  -  Send  C4I  Data  (Manage  Data  =»  Use  C4I) 

This  interface  transfers  data  from  a  training  system  to  C41  systems.  For  example,  an  operational  overlay 
created  by  the  training  staff  and  used  in  EXCON  can  be  distributed  to  the  C4I  systems  of  the  troops  that  are 
training.  It  coidd  also  be  possible  that  the  training  system  provides  status  infonnation  of  (simulated)  entities 
(either  “live”  dynamic  objects  or  “virtual”  players)  to  the  C41  systems. 

2.2. 5.8  E8  -  Event  Data  Exchange  (Manage  Data  <=>  Interface  with  External  Systems) 

This  interface  enables  the  exchange  of  data  between  systems,  which  can  influence  the  course  of  the  training 
session  and  generally  has  a  dynamic,  time  critical  character.  Examples  of  event  data  exchange  are  (updates 
of)  status  of  DOs  and  the  creation  of  a  minefield  in  one  system  (System  A),  which  is  communicated  to 
another  (System  B). 
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2.2.5.9  E9  -  DO  Association  and  Pairing  (Report  Status  =>  Sense) 

This  interface  enables  the  logical  linking  of  objects  in  the  training  environment;  this  includes  linking  of  DOs 
amongst  each  other  (DO  association)  and  linking  equipment  that  is  not  modelled  as  a  DO  with  DOs 
(equipment  pairing).  Examples  are: 

•  Personnel  mounting  and  dismounting  vehicles; 

•  Personnel  or  vehicles  entering  or  leaving  (parts  of)  buildings;  and 

•  Personnel  picking  up  weapons. 

2.2.5.10  E10  -  Exchange  Platform  Data  (Platform  Management  <=>  Engage) 

This  interface  enables  the  exchange  of  data  between  the  training  system  and  computers  (such  as  the  fire 
control  system  or  platform  management  system)  of  the  instrumented  real  systems.  This  is  a  bidirectional 
interface.  Data  exchange  from  the  platform  to  the  training  system  is  used  to  enable  or  influence  the 
behaviour  and  the  engagements  of  the  DO  in  the  training  environment.  Examples  are  selected  ammunition 
type,  dynamic  lead,  environmental  parameters  and  relevant  vehicle  parameters. 

Data  exchange  from  the  training  system  to  the  platform  is  used  to  influence  the  behaviour  of  the  real 
platform,  for  example  providing  the  platform  with  target  distance  information  delivered  from  the  training 
system  in  case  of  a  laser  based  training  system,  visualising  tracers  and  fall  of  shot  in  the  visual  sensors  or 
adding  sounds  to  the  communication  systems  (e.g.,  explosions,  messages  for  training  purposes). 

2.2.5.11  Ell  -  Reference  Data  Exchange  (Manage  Data  <=>  Store  Data) 

This  interface  enables  the  exchange  of  data  that  is  generally  used  for  reference  purposes,  e.g.  the  transfer 
from  System  A  to  System  B  of  an  ORBAT  definition,  damage  model  definitions,  geospatial  (terrain)  data 
such  as  the  layout  of  a  building  composed  of  separate  walls,  a  created  scenario  or  a  recorded  exercise. 
It  generally  contains  non-time  critical  information  and  is  therefore  used  mostly  prior  to  an  exercise,  but  it  can 
be  used  during  the  execution  of  an  exercise. 


2.3  MAPPING  FROM  FUNCTIONAL  TO  PHYSICAL 
2.3.1  The  OSI  Model 

The  OSI  (Open  System  Interconnection)  model  defines  a  networking  framework  to  implement  protocols  in 
seven  layers.  Control  is  passed  from  one  layer  to  the  next,  starting  at  the  application  layer  in  one  station, 
and  proceeding  to  the  bottom  layer,  over  the  channel  to  the  next  station  and  back  up  the  hierarchy. 

The  OSI  model  is  a  conceptual  framework  made  to  understand  complex  interactions  that  are  happening. 
The  OSI  model  takes  the  task  of  internetworking  and  divides  that  up  into  what  is  referred  to  as  a  vertical 
stack  that  consists  of  the  seven  layers  as  depicted  in  Figure  2-2. 

Since  the  UCATT  FA  describes  where  data  is  exchanged  between  systems  or  components,  the  OSI  7-layer 
model  applies.  To  achieve  interoperability  between  functions  it  is  therefore  necessary  to  address  not  just  the 
data  that  needs  to  be  sent  but  also  the  physical  implementation  of  how  that  data  is  transmitted  (e.g.  laser  or 
radio  in  the  case  of  E 1 ). 
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The  Seven  Layers  of  OSI 
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Figure  2-2:  The  Seven  Layer  OSI  Model. 


2.3.2  The  Relation  Between  External  Interfaces  and  Internal  Interfaces 

The  AG  specified  the  requirements  for  interoperability  at  the  application  level;  these  are  called  the  E- 
interfaces  (Es).  The  SG  translated  the  functional,  external  interfaces  into  the  lower  levels,  down  to  the 
physical  layer.  These  are  called  the  I-interfaces  (Is). 

When  going  into  the  physical  layer  of  interfaces  in  a  system,  functional  interfaces  (Es)  are  implemented  by 
physical  interfaces  (Is).  The  aim  of  the  UCATT  group  is  to  define  and  standardise  a  set  of  physical  interfaces 
to  allow  interoperability  between  systems  in  the  live  simulation  domain. 

It  should  be  noted  that  a  physical  interface  can  be  found  in  several  functional  interfaces.  For  example,  the 
laser  interface  (12)  is  used  for  direct  engagement  simulation  (El),  DO  technical  or  operational  status  control 
by  the  O/C  using  an  umpire  gun  (E2  and  E3)  and  for  indoor  positioning  (E3). 

As  of  this  report  the  identified  links  between  functional  and  physical  interfaces  are  summarised  in  the  table 
below. 


Table  2-1:  The  Identified  Relation  Between  Functional  and  Physical  Interfaces. 


El 

E2 

E3 

E4 

E5 

E6 

E7 

E8 

E9 

E10 

Ell 

11 

Long  Range  Radio 
(LRR),  DO  to  DO 

X 

12 

Laser 

X 

X 

X 

13 

Short  Range  Radio 
(SRR) 

X 
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El 

E2 

E3 

E4 

E5 

E6 

E7 

E8 

E9 

E10 

Ell 

14 

1R  -  short  range 

15 

TBD 

16 

TBD 

17 

TBD 

18 

TBD 

19 

TBD 

110 

Serial  interface 
between  TES  and 
radio  modem 

X 

X 

X 

Ill 

Long  range  radio, 

DO  to  EXCON 

X 

X 

X 

112 

Ethernet,  NC  to 
EXCON 

X 

When  looking  at  actual  simulation  systems  from  the  point  of  view  of  physical  interfaces  a  physical 
architecture  emerges,  showing  the  physical  implementation  of  functions.  Figure  2-3  below  gives  an  example 
of  a  physical  architecture.  This  example  is  purely  for  illustrative  purposes  and  is  not  intended  to  dictate 
system  design.  As  mentioned  earlier  in  this  report,  the  intent  of  UCATT  is  to  enable  flexible  system  design, 
enable  industry  to  fulfil  their  customers’  needs,  while  still  achieving  UCATT  interoperability. 


Figure  2-3:  Example  Physical  Architecture. 
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2.4  PRIORITIES  FOR  STANDARDISATION 

2.4.1  Introduction 

The  UCATT  TG  has  identified  a  total  of  11  External  Interfaces.  It  requires  a  substantial  effort  both  in 
manpower  and  in  time  to  define  a  new  standard  for  each  interface.  Although  for  some  UCATT  external 
interfaces  existing  standards  can  be  used,  it  is  unrealistic  to  expect  that  the  whole  family  of  UCATT 
standards  (in  one  or  more  of  their  physical  implementations)  can  be  defined  simultaneously.  Therefore  the 
UCATT  TG  decided  to  prioritise  the  sequence  in  which  standards  for  external  interfaces  will  be  developed, 
both  in  terms  of  functional  interfaces  and  of  physical  interfaces. 

2.4.2  Priorities  for  the  Functional  Interfaces 

The  priorities  for  development  of  standards  for  the  functional  external  interfaces  are  driven  by  User 
requirements,  taking  the  Use  Cases  as  reference.  This  prioritisation  and  the  underlying  arguments  are 
described  below: 

1)  The  first  priority  of  standards  to  develop  was  the  El  interface.  The  engagement  between  dynamic 
objects  of  different  training  systems  is  the  most  basic  functionality  required.  Interaction  of  players  in 
the  field  is  essential  to  all  identified  Use  Cases.  Different  training  systems  have  different  architectures 
and  different  ways  to  implement  engagements.  Two  totally  different  implementations  are  for 
example  systems  using  line-of-sight  engagements  (such  as  laser)  and  systems  using  the  geo-pairing 
mechanism.  This  requires  different  physical  implementations  of  the  El  interface.  It  was  decided  to 
first  define  a  standard  for  laser  based  systems  (El/12),  because  this  type  of  system  is  currently 
widely  used  by  many  nations,  who  already  operate  and  train  together,  and  who  have  a  requirement 
to  use  their  training  systems  in  joint  and  combined  exercises. 

2)  Closely  related  to  enabling  engagements,  is  the  ability  of  dynamic  objects  to  report  their  status  and 
the  results  of  such  engagements,  both  to  the  players  in  the  field  and  to  the  EXCON(s).  Therefore  the 
E4  interface  is  the  second  priority. 

3)  The  third  priority  is  the  ability  to  set  or  influence  the  status  of  dynamic  objects  from  the  EXCON  of 
another  training  system.  This  requires  the  E2  interface  (training  system  status  change)  and  the  E3 
interface  (DO  status  change).  It  is  assessed  likely  that  E2  and  E3  will  be  mapped  on  the  same 
physical  interface,  that  only  the  dataset  will  be  different  and  that  both  interfaces  will  be  defined 
simultaneously.  Therefore  E2  and  E3  are  listed  together  as  priority  3. 

With  El  through  E4  implemented,  it  is  possible  to  use  DOs  from  different  training  systems  in  the  same 
exercise,  without  requiring  their  own  EXCON  capabilities.  Only  one  (local)  EXCON  is  required  to  monitor 
and  control  the  exercise  and  to  create  AARs.  This  would  substantially  reduce  the  technical  and  logistical 
efforts  to  facilitate  a  joint  and  combined  exercise. 

4)  The  next  priority  is  to  enable  data  exchange  at  the  training  system  level,  for  example  to  exchange 
data  between  different  EXCONs.  This  is  the  E8  interface.  With  this  interface  it  is  possible  that  all 
involved  systems  can  display  all  relevant  information  in  a  synchronised  way,  resulting  in  a  complete 
and  up-to-date  operational  picture  of  the  exercise.  In  addition,  this  interface  can  contain 
functionality  to  control  DOs  of  another  training  system  through  their  own  EXCON.  E8  can  be 
defined  to  include  the  E2,  E3  and  E4  functionality.  Having  El  and  E8  implemented  in  this  way,  it  is 
possible  to  use  DOs  from  different  training  systems  in  the  same  exercise,  however  requiring  all 
related  EXCONs  to  be  present  and  interconnected.  In  fact,  the  successful  UCATT  demonstration  in 
September  2010  used  parts  of  El,  E4  and  E8  to  show  the  potential  of  the  UCATT  standards. 

The  remaining  external  interfaces  have  a  lower  priority.  The  E9  interface  enables  the  logical  linking  of 
objects  in  the  training  environment,  such  as  linking  DOs  amongst  each  other  (DO  association)  and  linking 
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DOs  with  equipment  that  is  not  modelled  as  DOs  (equipment  pairing).  The  E6  and  E7  interfaces  enable  the 
interoperability  of  training  systems  and  C4I  systems.  It  is  likely  that  the  main  effort  to  define  these  standards 
will  be  driven  and  performed  by  other  standardisation  groups.  The  UCATT  TG  should  remain  connected  to 
these  developments  to  ensure  that  live  training  system  specific  requirements  will  be  incorporated  in  those 
standards.  The  E5  interface  enables  the  communication  between  training  staff  members  of  different  systems 
operating  in  the  same  exercise.  It  is  likely  that  commercially  available  standards  can  be  used  for  this 
interface.  The  Ell  interface  enables  the  exchange  of  non-time  critical  reference  data,  facilitating  exercise 
definition  and  initialisation  and  exercise  evaluation.  It  is  likely  that  also  for  this  interface  existing  standards 
can  be  used.  Finally,  the  E10  interface  enables  the  interaction  between  the  training  system  and  the 
(computers  of  the)  operational  platforms.  This  interface  is  a  complex  one,  because  it  must  accommodate 
many  different  platform  specific  instances. 

2.4.3  Priorities  for  the  Physical  Interfaces 

As  can  be  inferred  from  Table  2-1,  three  types  of  physical  interfaces  were  identified  for  the  implementation 
of  El.  History  and  technological  development  presents  the  laser  optical  implementation  as  the  most 
simple  and  effective  method  of  simulation  of  ballistic  effect  in  the  kinetic  battle.  This  places  the  Laser  as 
overwhelmingly  most  common  form  of  El  and  it  is  on  that  basis  the  Laser  physical  interface  (12)  was  chosen 
as  the  priority. 

Through  time,  Industry  have  developed  the  techniques  and  various  encoding  implementations  that  are  now 
in-service.  The  selection  of  which  by  individual  procurement  authorities  is  likely  to  be  a  strong  function  of 
the  acquisition  timeframe  (thus  code  availability)  and  particular  beneficial  characteristics  (and  limitations). 
The  work  of  the  UCATT  Standards  Group  (MSG-099)  has  been  to  establish  a  most  suitable  code  for  the 
UCATT  Interface  Standard  for  Laser  Engagement. 

Against  the  data  requirements  set  out  in  this  report,  the  MSG-099  determined  that  the  development  of  a 
completely  new  coding  was  inappropriate  for  multiple  reasons  including  cost  and  timeframe.  Instead  it  was 
decided  to  analyse  the  most  common  codes  to  determine  their  applicability  for  development  to  meet  the 
operational  and  interoperability  requirements  of  today  and  the  future.  The  codes  selected  were  MILES, 
OSAG,  NCL  and  COS1M. 

Each  code  was  analysed  with  particular  reference  to  the  required  engagement  data,  potential  for 
interoperability  with  extant  coding  and  further  growth  and  development  potential.  In  addition  the  analysis 
included  consideration  of  other  engineering  and  operational  factors  impacting  combat  system  design  such  as 
the  impact  upon  receiver  sensitivity  and  emitter  power,  range  and  propagation  and  performance  in  different 
weather  conditions,  eye  safety  and  issues  such  as  the  ownership  of  the  Intellectual  Property.  Physical 
characteristics,  data  handling  capability  and  protocol  used  informed  the  full  analysis  to  the  point  that  enabled 
the  selection  of  OSAG  2.0  Standard  as  the  baseline  UCATT  Interface  Standard  for  Laser  Engagement  during 
2012.  The  selection  was  made  by  vote  of  eligible  UCATT  members  in  accordance  with  the  UCATT  Rules  of 
Order.  Members  were  asked  to  consider  a  balance  of  issues  ranging  from  technical  features  and  capability, 
to  investments  and  the  installed  base. 

Some  key  features  of  OSAG  2.0  that  make  it  attractive  as  the  baseline  for  the  UCATT  Interface  Standard  for 
Laser  Engagement  include  its  short  pule  and  transmission  times  that  lead  to  limited  energy  and  improved 
laser  safety  (typically  Class  1 )  and  low  transmitter  battery  consumption,  its  good  scaling  capacity  (for  the 
number  of  small  arms,  heavy  weapons,  and  ammunition  types),  efficiency  and  reliability  via  error 
detection/correction  and  potential  for  future  expansion  of  transmitted  parameters  (as  GPS  coordinates). 

Further  information  regarding  the  codes  reviewed  and  work  subsequent  to  the  2012  selection  may  be  found 
in  the  report  for  MSG-099. 
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The  second  functional  external  interface  to  define  a  standard  for,  is  E4,  the  DO  reporting  function. 
This  interface  transfers  information  from  a  DO  to  other  parts  of  the  training  system,  typically  to  EXCON. 
Referring  to  the  UCATT  Use  Cases,  the  need  for  the  external  interface  E4  arises  when  trainees  use  another 
nation’s  training  site  and  training  facilities  (the  host  site),  while  bringing  their  own  operational  equipment 
and  their  own  Tactical  Engagement  Simulation  (TES)  equipment.  When  information  has  to  be  transferred 
from  the  TES  equipment  to  the  host  system’s  EXCON,  a  number  of  solutions  can  be  implemented  (see  also 
Figure  2-4): 

•  Option  1 ,  the  host  system  provides  each  DO  with  a  radio  that  has  to  interface  with  the  visiting  TES 
equipment.  This  physical  interface  is  called  110  and  typically  requires  a  serial  interface. 

•  Option  2,  the  visiting  DOs  bring  their  own  radios,  connected  to  or  integrated  in  their  TES  equipment. 
The  visiting  radios  now  have  to  communicate  with  the  host’s  radio  system.  This  physical  interface  is 
called  Ill  and  requires  a  long  range  radio  interface. 

•  Option  3,  the  visitors  also  bring  their  own  radio  communication  system,  possibly  with  masts  to 
establish  a  full  coverage  of  the  training  area.  In  this  case,  E4  is  located  between  the  visiting  system’s 
radio  network  controller  and  the  host  EXCON.  This  physical  interface  is  called  112  and  is  typically 
implemented  through  an  Ethernet  interface. 

•  Option  4  is  the  combined  solution,  where  a  DO  is  equipped  with  both  his  own  and  a  host  system’s 
radio  (110),  the  radios  can  communicate  with  both  radio  systems  (Ill)  and  also  the  radio  network 
controllers  can  interface  with  both  EXCONs  (112). 


Figure  2-4:  Different  Options  for  Physical  Implementation  of  the  E4  Interface. 


The  implementation  of  110  as  physical  interface  for  E4  requires  that  the  TES  must  be  able  to  interface  with 
different  types  of  radio.  The  predominant  advantage  of  this  solution  is  that  one  automatically  complies  with 
the  local  communication  regulations  (e.g.  bandwidth,  frequency,  power,  voltage).  However,  this  solution 
requires  additional  hardware,  the  extra  radios  for  the  host  system  need  to  be  provided  either  by  the  visiting 
troops  or  by  the  host  system.  A  disadvantage  is  that  there  possibly  can  be  a  quality  of  service  mismatch 
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between  the  TES  and  the  other  radio  system  (e.g.  a  different  update  frequency).  Also,  in  this  situation  where 
only  one  radio  is  used,  only  the  host  EXCON  can  be  used,  possibly  leading  to  a  loss  of  capabilities  of  the 
visiting’s  training  system.  Furthermore,  some  training  systems  use  radios  as  relay  to  communicate  with 
EXCON  (short  range  and  long  range).  Such  a  requirement  would  demand  a  custom  solution. 

The  implementation  of  111  as  physical  interface  for  E4  requires  that  radio  frequencies  and  power  must  be 
standardised  and  harmonised.  Within  NATO  there  are  provisions  for  enabling  this.  An  advantage  is  that  this 
is  an  “air”  interface,  it  does  not  require  additional  and/or  extra  cables,  plugs,  power,  power  management, 
batteries  etc.  It  is  also  logistically  very  easy  to  support.  However,  in  this  situation  only  the  host  EXCON  is 
used,  possibly  leading  to  a  loss  of  capabilities  of  the  visiting’s  training  system. 

The  implementation  of  112  as  physical  interface  for  E4  requires  that  the  visiting  troops  also  bring  their  own 
communication  system,  which  therefore  must  be  mobile  and  transportable.  This  can  be  an  expensive  solution 
and  might  result  in  challenges  regarding  radio  coverage  and  frequency  management  at  the  host’s  site.  In  this 
solution  there  is  a  choice  to  use  one  or  more  EXCONs,  but  if  only  one  EXCON  is  used,  there  can  be  a  loss  of 
capabilities  of  one  of  the  training  systems. 

Given  these  arguments,  from  a  user  point  of  view  11 1  is  the  most  preferable  physical  implementation  of  E4. 
It  is  most  efficient  related  to  costs,  logistics,  frequency  management,  user  friendliness  and  fidelity  between 
the  participants.  The  next  best  option  is  110  and  112  comes  in  last  place,  because  this  solution  requires  a  fully 
mobile  training  system. 

Having  multiple  physical  interfaces  (110,  II 1  and  12)  allows  for  maximum  flexibility  and  can  preserve  more 
advanced  capabilities  when  the  host  system  has  less. 
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3.1  DO  DYNAMIC  MODEL 

The  DO  dynamic  model  is  the  mechanism  that  determines  the  new  status  of  a  DO  based  on  its  current  status, 
its  properties  and  an  engagement  affecting  the  DO.  A  common  name  for  the  dynamic  model  is  also 
vulnerability  model.  The  name  “vulnerability  model”  might  suggest  that  this  model  only  determines  the 
effects  of  weapons  but  this  model  also  takes  care  of  repair  and  medical  activities  (thus  reversing  the  status 
towards  a  more  operational  level).  Also  resupply  engagements  can  be  part  of  this  model. 

Generally,  the  DO  dynamic  model  is  triggered  by  an  engagement  and  will  determine  the  resulting  change  of 
DO  status  (if  any).  However,  the  status  change  mechanism  can  also  be  more  complex,  without  directly 
changing  the  operational  status  of  the  DO.  One  example  is  a  time-dependent  function:  when  a  wounded  or 
contaminated  person  is  not  or  wrongly  treated,  the  effect(s)  can  become  worse  and  the  patient  could 
eventually  die.  Such  a  mechanism  can  also  be  implemented  for  vehicles:  when  not  repaired  or  maintained  it 
might  further  degrade. 

Another  example  is  that  multiple  engagements  are  required  to  change  the  status  of  a  DO.  When  one  bullet  is 
fired  at  a  structure  such  as  a  wall,  it  will  probably  not  be  damaged  or  destroyed.  However,  when  multiple  hits 
of  larger  calibre  bullets  are  fired  at  the  wall,  it  may  become  damaged  or  even  destroyed,  so  only  the 
cumulative  effects  will  change  the  status. 

To  be  UCATT  interoperable  in  respect  of  the  DO  dynamic  model,  a  training  system  must  satisfy  two 
conditions: 

1 )  The  input  to  the  model  must  be  standardised  and  those  requirements  are  listed  in  the  datasets  of  the 
external  interfaces. 

2)  The  output  of  the  model  (the  result  of  the  engagement)  must  be  standardised  and  the  definition  of 
this  output  (the  DO  status),  is  provided  in  Annex  D. 

If  the  input  and  output  sets  between  two  systems  are  not  the  same,  a  mapping  must  be  made.  The  definition 
of  model  output  and  a  mapping  between  different  levels  of  detail  are  provided  in  Annex  D. 

When  satisfying  these  two  requirements,  technical  interoperability  is  enabled  and  the  DO  dynamic  model 
can  be  considered  as  a  black  box  function.  It  is  still  possible  that  two  training  systems  with  different  levels  of 
statuses  can  interoperate.  When  each  training  system  is  responsible  for  determining  the  results  of  each 
engagement  on  its  own  DOs,  not  even  a  mapping  between  the  statuses  is  required.  However,  when  a  training 
system  must  change  the  status  of  a  DO  from  another  training  system  with  a  lower  level  of  detail  of  statuses 
or  when  the  statuses  of  DOs  must  be  monitored  in  a  training  system  with  a  lower  level  of  detail  of  statuses,  a 
mapping  is  required. 

There  are  two  ways  to  map  a  detailed  status  to  a  higher  level  status: 

1)  The  lower  level  status  is  mapped  onto  the  higher  level  associated  status,  such  as  the  mapping  of  a 
“main  gun  kill”  onto  the  more  general  “weapon  kill”. 

2)  The  lower  level  status  is  discarded  (or  mapped  onto  the  current  status  of  the  DO),  such  as  the 
mapping  of  a  “secondary  weapon  kill”  onto  “operational”,  since  the  main  gun  is  still  operational  and 
therefore  a  “weapon  kill”  is  too  strong. 

Under  these  conditions  each  training  system  can  use  its  own  DO  dynamic  model.  Those  models  can  be  based 
on  the  same  mechanism  (e.g.,  kill  probability  look-up  tables)  but  using  a  different  dataset,  or  they  can  be 
based  on  totally  different  principles.  Even  when  they  use  the  same  type  of  mechanism,  differences  can  occur 
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due  to  level  of  detail.  For  example,  a  common  mechanism  to  simulate  different  levels  of  protection  on  a  DO, 
and  thus  different  outcomes  of  an  engagement,  is  a  3D  representation  of  a  DO.  Some  systems  use  a  simple 
representation,  for  example  a  rectangular  box,  distinguishing  only  front,  back,  left,  right,  top  and  bottom. 
Other  systems  can  make  use  of  far  more  complex  representations,  distinguishing  maybe  hundreds  of 
polygons,  each  with  different  values  for  protection  and  possible  outcomes  of  an  engagement.  As  long  as  the 
input  and  output  are  standardised,  the  systems  can  interoperate. 

However,  from  a  User  perspective,  interoperability  also  requires  a  certain  level  of  “fair  fight”,  that  means 
that  the  results  of  engagements  between  types  of  DO  within  and  between  the  training  systems,  must  be 
statistically  and  tactically  comparable.  If  an  engagement  between  a  DO  from  System  A  on  a  DO  from 
System  B  will  consistently  give  different  results  than  that  of  the  same  engagement  between  the  same  types  of 
DO  from  System  B  and  A,  the  interoperability  of  the  systems  will  lose  its  credibility  and  thereby  it 
usefulness. 

A  fair  fight  can  be  ensured  by  using  the  same  DO  dynamic  model  and  the  same  dataset  or  by  tuning  the  DO 
dynamic  models  of  the  involved  training  systems.  The  consequences  of  the  differences  in  DO  dynamic 
model  from  different  training  systems  must  be  analysed  in  the  context  of  training  objectives  and  based  on 
that  comparison,  the  commanders  must  decide  to  accept  the  consequences  or  not  (and  thus  not  use  the  mix  of 
training  systems).  This  will  be  a  case  by  case  decision. 


3.2  EXTERNAL  SYSTEMS 

3.2.1  Definition  of  External  Systems 

External  systems  in  the  UCATT  context  are  those  systems  that  are  not  an  integral  part  of  a  particular 
UCATT  training  system  and  with  which  the  training  system  equipment  must  interface.  Examples  of  external 
systems  are:  another  (UCATT)  live  training  system,  a  virtual  or  constructive  simulation,  a  C4I  system  and  a 
weapon  system.  When  instrumented  by  the  training  system,  a  weapon  system  becomes  part  of  the  exercise, 
but  from  the  UCATT  training  system  perspective  it  is  an  external  system. 

3.2.2  Live  -  Virtual  -  Constructive  Simulations 

The  current  level  of  technology  allows  for  a  deeper  integration  of  simulation  systems  into  a  single  simulated 
battlefield.  Most  countries  are  pursuing  LVC  (Live,  Virtual,  Constructive)  programmes  of  some  kind.  The 
purpose  of  LVC  is  to  leverage  the  strong  points  of  one  domain  to  fill  gaps  in  another.  In  those  cases  data  is 
either  injected  into  the  live  simulation  system  from  virtual  or  constructive  systems  or  vice  versa.  Therefore 
UCATT  has  made  efforts  to  anticipate  the  possibility  of  not  only  connecting  to  other  live  simulation  systems, 
but  also  virtual  or  constructive  simulators. 

The  most  likely  method  of  connecting  to  non-live  simulators  is  considered  to  be  through  the  E8  interface 
(Event  Data  Exchange).  Although  decisions  have  not  been  made  for  that  interface,  existing  standards 
like  HLA,  D1S  or  TENA  have  been  investigated  and  are  considered  viable  candidates  to  achieve  LVC 
connectivity.  Illustrations  of  such  arrangements  can  be  found  in  Annex  1. 

3.2.3  C4I  Systems 

From  a  training  point  of  view  and  possibly  for  reasons  of  cost-effectiveness,  it  is  desirable  that  trainees  can 
use  their  operational  C4I  systems  in  a  UCATT  environment,  instead  of  being  provided  with  simulated 
equipment  only  used  for  training  purposes.  The  external  interfaces  E6  (receive  C41  data)  and  E7  (send  C41 
data)  enable  the  training  system  to  exchange  information  with  such  operational  C41  systems. 

There  are  several  example  situations  for  the  implementation  of  E6  and  E7. 
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3.2.3. 1  Logging  and  Replay  of  C4I  Data  for  Monitoring  and  AAR  Purposes 

The  data  from  C4I  systems  is  captured  and  typical  examples  are: 

•  Record  the  relevant  data  in  order  to  be  able  to  reconstruct  the  recognised  common  operational 
picture,  generated  by  the  C4I  system,  at  any  moment  in  time  (e.g.,  status  of  entities/units,  overlays, 
orders,  reports).  This  must  be  synchronised  with  the  other  data  in  the  training  system. 

•  Retrieve  who  created  certain  data  (e.g.,  spot  reports,  orders). 

•  Retrieve  which  user  was  accessing  what  information  at  a  certain  moment  in  time  (“snapshots”  from 
every  user)  (only  if  this  information  is  recorded  in  the  C4I  systems). 

In  many  cases  operational  C41  systems  do  not  possess  functionality  to  log  and/or  replay  the  above  mentioned 
data  elements.  In  these  cases  this  functionality  must  be  provided  by  the  training  system.  It  requires  at  least 
the  functionality  of  the  training  system  to  receive  C4I  data  (E6)  and  when  the  operational  C4I  systems  are 
involved  in  the  replay,  also  the  functionality  to  send  C4I  data  (E7). 

3.2.3.2  Synthetic  Wrap,  Feed  Information  from  the  Training  System  into  C4I  Systems 

An  exercise  with  live  players  can  be  enriched  by  virtual  entities.  In  the  case  of  a  full  integration,  live  and 
virtual  players  should  be  able  to  interact  with  each  other.  On  the  short  term,  this  scenario  is  not  the  driving 
force  for  UCATT,  since  it  requires  some  innovative  technical  solution  to  enable  live  players  to  observe 
virtual  players  (both  visually  and  through  sensors)  and  interact  with  them.  The  other  way  around  is 
technically  less  complex.  However,  there  are  already  implementations  of  virtual  and  live  integration,  where 
live  players  can  observe  virtual  entities  and  the  effects  they  produce  and  can  even  interact  with  those  virtual 
entities.  For  example  forward  observers,  who  are  equipped  with  special  binoculars  through  which  they  can 
see  virtual  planes  and  helicopters,  and  observe  the  results  of  simulated  fire  support.  Or  soldiers  who  can 
engage  virtual  targets  in  shooting  houses,  where  the  targets  are  projected  on  the  walls.  See  Annex  I  for  a 
further  description  of  these  examples. 

But  even  if  live  and  virtual  players  cannot  observe  each  other,  there  is  a  good  reason  to  connect  a  live 
training  system  to  virtual  and/or  constructive  simulations.  It  enables  the  live  play  to  be  embedded  in  a  much 
larger  context,  with  simulated  flanking  and  higher  level  units.  The  live  players  can  be  made  aware  of  this 
larger  context  by  messages  on  their  radio  nets,  but  can  also  monitor  the  presence  and  activities  of  virtual  or 
constructive  entities  on  their  C4I  systems.  This  requires  an  interface  from  the  training  system  to  the  C4I 
systems  (E7). 

It  is  recognised  that  not  all  information  of  virtual  and  constructive  entities  should  be  indiscriminately 
exchanged  with  the  C4I  systems  of  live  players.  Instead,  some  filters  must  be  implemented,  because  for 
example  it  is  not  desirable  that  live  players  get  (automatic)  position  and  status  updates  of  the  simulated 
enemy. 

Another  example  of  this  Synthetic  Wrap  functionality  is  that  the  C4I  systems  are  provided  with  certain 
characteristics  of  (selected)  simulated  engagement  areas,  such  as  minefields  and  CBRN  areas.  These 
simulated  engagement  areas  are  defined  in  and  managed  by  the  training  system  (EXCON).  There  might  be 
situations,  for  example  when  EXCON  also  acts  as  higher  control,  that  the  training  staff  has  to  provide  the 
C4I  systems  of  the  trainees  with  for  example  the  location  of  a  minefield  or  a  contaminated  area.  This  kind  of 
data  typically  ends  up  in  specific  overlays  used  by  the  C4I  system.  The  distribution  of  this  data  is  can  be 
prior  to  an  exercise,  as  part  of  the  scenario  definition,  but  engagement  areas  can  also  be  created  and  changed 
during  the  execution  of  an  exercise. 

The  easiest  way  to  transfer  this  type  of  data  is  to  copy  the  data  from  the  training  system  by  manually  entering 
it  into  the  C4I  system.  However,  this  can  be  laboriously  and  prone  to  mistakes.  Another  solution  is  to  transfer 
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information  of  engagement  areas  from  the  training  system  directly  into  the  C4I  systems,  avoiding 
discrepancies  between  data  in  the  training  system  and  data  in  the  C4I  systems.  This  requires  the  E7  interface. 
What  data  (which  characteristics  of  which  engagement  areas)  is  transferred  when  must  always  be  under 
training  staff  control. 

3.2.3.3  Feed  Information  from  C4I  Systems  into  the  Training  System 

Transferring  information  the  other  way  around,  from  C4I  systems  into  the  training  system  is  also  a  possible 
example  situation.  For  example,  the  trainees  can  lay  a  minefield  in  the  live  training  environment  and  define 
its  location  in  the  C4I  system.  The  existence  of  the  minefield  must  also  be  known  in  the  training  system, 
especially  when  the  training  system  is  responsible  for  detecting  engagements  between  the  (simulated) 
minefield  and  DOs  and/or  for  determining  the  results  of  such  engagements.  This  data  can  be  provided  to  the 
training  system  prior  to  an  exercise  or  during  its  execution.  Another  example  is  a  call  for  fire,  entered  into 
the  C41  system  used  by  a  forward  observer  or  a  Fire  Support  Coordination  Centre  to  direct  fire. 

Also  here  there  are  several  ways  to  implement  this  data  transfer: 

•  Manually  by  the  training  staff  where  training  staff  read  the  data  from  the  C4I  system  and  it  is 
entered  manually  into  the  training  system  (“swivel  chair  interface”)  so  that  a  difference  between  the 
data  in  the  C41  systems  (e.g.,  the  perceived  location  of  a  minefield)  and  the  actual  data  (e.g.,  the  real 
location  of  the  emplaced  mines)  can  be  created. 

•  Semi-automatically,  on  command  of  the  training  staff,  whereby  the  exact  data  from  the  C4I  system 
(e.g.,  a  call  for  fire)  is  transferred  into  the  training  system,  but  the  training  staff  decides  on  which 
data  will  be  transferred  and  at  what  time  (requires  the  E6  interface). 

•  Automatically,  the  data  is  real-time  transferred  from  the  C41  system  into  the  training  system 
(e.g.,  orders  to  units  or  entities),  without  control  of  the  training  staff. 

3.2.3.4  Cyber  -  Training  System  Influencing  C4I  Systems 

Cyberspace,  or  shortly  cyber,  is  defined  as  the  digital  environment,  consisting  of  computer  equipment  and 
services.  The  use  of  digital  assets  by  the  military  is  evolving  strongly.  Be  it  in  weapon  systems,  command 
and  control  systems  or  in  logistic  and  administrative  systems,  they  are  increasingly  becoming  an  integral  part 
of  military  operations,  accelerating  processes  and  forming  a  critical  capability.  Besides  the  use  of  dedicated 
military  equipment,  the  military  are  also  directly  or  indirectly  making  use  of  civil  digital  infrastructure, 
like  telecommunication  networks  and  power  grids.  At  the  same  time,  the  growing  dependence  on  digital 
assets  also  creates  vulnerabilities.  Therefore,  cyberspace  has  developed  into  the  fifth  domain  for  military 
operations,  along  with  land,  air,  sea  and  space. 

Cyberspace  can  be  subdivided  into  several  layers.  A  simple  model  consists  of  three  layers: 

•  The  lowest  layer  is  the  physical  layer,  consisting  of  the  hardware  and  physical  infrastructure  of 
cyberspace,  such  as  the  computers,  routers,  cables,  storage  devices,  etc. 

•  The  middle  layer  is  the  logical  layer  and  makes  the  physical  layer  work  consisting  of  operating 
systems,  software  (applications)  and  data  that  is  stored  on  and  processed  by  the  physical  layer. 

•  The  top  layer  is  the  social  layer,  consisting  of  the  people  and  organisations  that  make  use  of 
cyberspace. 

The  layers  are  closely  connected  and  cyberspace  can  only  function  when  all  layers  interoperate. 
Nevertheless,  the  main  point  of  action  for  cyber-attacks  is  the  logical  layer.  By  intruding  in  and  interfering 
with  the  logical  layer,  effects  can  be  achieved  in  other  layers.  For  example,  changing  the  mechanisms  of 
Supervisory  Control  and  Data  Acquisition  programmes,  hardware  can  be  forced  to  malfunction  or  even 
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sustain  physical  damage.  On  the  other  hand,  interfering  with  the  logical  layer  can  change  the  data  and 
services  provided  to  the  end  users,  possibly  influencing  their  behaviour,  the  ultimate  goal  of  cyber-attacks. 

In  cyberspace  one’s  own  digital  assets  must  be  protected  (defensive  cyber  operations)  and  the  digital  assets 
of  an  opponent  might  be  attacked  (either  for  intelligence  or  offensive  cyber  operations). 

The  effects  that  can  be  achieved  in  the  logical  layer  of  cyberspace,  that  must  be  maintained  and  protected  in 
own  systems  and  must  be  disrupted  in  systems  of  an  opponent,  can  be  categorised  as: 

•  Confidentiality,  unauthorised  gaining  access  to  information  from  digital  systems,  such  as  when  an 
opponent  is  able  to  look  at  the  operation  plans  stored  in  a  battlefield  management  system. 

•  Integrity,  unauthorised  manipulation  of  data  or  functionality  of  processes,  such  as  when  an 
opponent  is  able  to  change  the  location  of  an  entity  displayed  on  a  battlefield  management  system. 

•  Availability,  unauthorised  affecting  the  availability  of  data  or  the  level  of  service  of  processes,  such 
as  when  an  opponent  can  disrupt  the  data  exchange  or  completely  block  the  functioning  of  a 
battlefield  management  system. 

Cyberspace  is  present  in  the  urban  battlefield,  even  at  the  lowest  level.  Units  and  even  individual  soldiers  are 
relying  on  computerised  systems  for  situational  awareness,  command  and  control,  communication, 
navigation  and  engagement  of  an  opponent. 

Although  the  offensive  use  of  cyber  means  is  planned  and  probably  executed  at  the  strategic  level,  units  in 
the  urban  environment  can  be  subject  to  its  effect.  Even  at  company  or  platoon  level,  disrupting  or  corrupting 
C4I  systems  or  platform  management  systems  may  have  major  impact  upon  unit  effectiveness.  Because  it  is 
likely  that  future  units  and  individual  systems  can  be  subject  to  cyber-attacks  and  because  of  the  severity  of 
the  resulting  effects  on  performance,  there  is  a  need  to  train  units  and  commanders  in  a  live  training 
environment  to  deal  with  cyber  warfare  and  the  loss  of  functionality  of  computerised  systems. 

Therefore  it  is  desirable  that  cyber  injects  can  be  initiated  from  the  training  system  (EXCON)  into 
operational  C4I  systems.  Possible  injects  may  include: 

•  Disrupting  the  integrity  of  the  information,  such  as  changing  entity  location  data  or  changing  the 
information  displayed  on  overlays. 

•  Disrupting  the  availability  of  data  or  functionality,  such  as  freezing  the  user-interface  or  blocking 
information  being  exchanged. 

Some  effects  of  cyber-attacks  can  readily  be  mapped  on  certain  damage  statuses,  such  as  “C4ISR  kill”, 
“BMS  computer  kill”  and  “Data  communications  corrupted”. 

The  UCATT  assumption  is  that  the  involved  C4I  systems  must  have  a  built-in  capability  to  handle  simulated 
cyber  incidents  for  training  purposes.  This  capability  is  therefore  outside  the  scope  of  UCATT. 

The  AG  also  identified  that  interfacing  with  other  systems  has  information  security  aspects,  but  they  are  not 
explored,  neither  is  protecting  the  cyber  security  of  the  training  system  itself  addressed  by  the  AG. 


3.3  EXTERNAL  INTERFACE  DEFINITIONS 

This  section  describes  the  main  subjects  and  principles  that  were  explored  during  the  definition  of  each 
External  interface  (Es).  The  detailed  specification  of  the  data  elements  that  are  part  of  an  interface,  are  listed 
in  the  Annexes. 
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3.3.1  General  Remarks 

An  External  interface  transfers  the  required  data  between  two  system  functions.  The  dataset  of  each  External 
interface  is  defined  as  a  “superset”,  that  means  that  the  set  contains  all  possible  data  elements  to  support  the 
different  interactions  between  the  two  system  functions  and  also  different  system  designs,  where  functions 
reside  in  different  parts  of  the  system  and  therefore  require  different  mechanisms  for  data  transfer. 

An  example  of  the  former  at  the  level  of  detail  of  the  UCATT  FA  might  be  an  engagement  which  is  an  event 
from  outside  a  DO  that  can  change  the  status  of  that  DO.  There  are  many  different  types  of  engagement. 
Being  hit  by  a  bullet,  being  exposed  to  a  CBRN  area  or  being  repaired,  are  different  types  of  engagement, 
and  thus  require  different  data  elements.  But  all  these  data  elements  are  part  of  the  engagement  interface. 
An  example  of  a  comparison  of  different  required  data  elements  for  different  types  of  engagement  is  given  in 
Table  E-2  in  Annex  E. 

An  example  of  the  latter  may  be  where  functions  reside  in  different  parts  of  the  system  and  therefore  require 
different  mechanisms  for  data  transfer.  For  example,  to  simulate  the  hit  of  a  bullet,  a  totally  different  dataset 
is  required  in  a  system  based  on  one-way  line  of  sight  engagements  (e.g.,  laser)  than  in  a  system  based  on 
geo-pairing.  An  example  of  this  comparison  is  described  in  Table  3-1.  Thus  the  term  “superset”  is  used  to 
express  that  for  a  specific  interaction  between  two  system  functions,  generally  only  a  subset  of  the  defined 
data  elements  are  required  as  opposed  to  the  complete  list.  In  the  definition  of  the  supersets,  the  relevant 
subsets  are  distinguished. 


Table  3-1:  Example  Engagement  Datasets  of  Different  System  Designs. 


One-Way  Line  of  Sight  Method 

Geo-Pairing  Method 

Shooter  ID 

(green) 

Shooter  ID 

(green) 

Shooter  location 

(red) 

Shooter  location 

(green) 

Shooter  velocity 

(red) 

Shooter  velocity 

(green) 

Weapon  type 

(red) 

Weapon  type 

(green) 

Weapon  direction/angle 

(red) 

Weapon  direction/angle 

(green) 

Ammunition  type 

(green) 

Ammunition  type 

(green) 

Engagement  range 

(red) 

Engagement  range 

(yellow) 

Terrain 

(red) 

Terrain 

(yellow) 

Affected  DO  ID 

(yellow) 

Affected  DO  ID 

(green) 

Affected  DO  location 

(red) 

Affected  DO  location 

(green) 

Affected  DO(s)  velocity 

(red) 

Affected  DO(s)  velocity 

(green) 

Trigger  time 

(red) 

Trigger  time 

(green) 

Impact  time 

(yellow) 

Impact  time 

(yellow) 

Point  of  impact 

(yellow) 

Point  of  impact 

(yellow) 

Projectile  impact  velocity 

(yellow) 

Projectile  impact  velocity 

(yellow) 

3.3. 1.1  Time 

Time  related  to  data  transfer  within  the  training  system  must  be  based  on  a  common  reference  time, 
for  example  GPS  time. 
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3.3. 1.2  Time  Stamps 

It  is  assumed  that  all  messages  transferred  via  the  external  interfaces  are  labelled  with  the  time  they  were 
generated  or  received. 


3.3. 1.3  DO  Identifications  (IDs) 

These  are  the  unique  identifications  of  DOs  and  used  by  a  training  system  to  distinguish  the  different  DOs. 
These  IDs  are  also  important  to  maintenance  personnel  of  a  training  system.  But  to  operational  users  of  a 
training  system,  like  trainees  and  O/Cs,  the  DO  IDs  are  generally  not  meaningful,  especially  when  dealing 
with  personnel  and  vehicles  where  Users  are  generally  more  interested  in  the  associated  call  sign.  It  is 
assumed  that  a  training  system  has  the  mapping  of  DO  ID  and  call  sign  available. 

The  requirement  to  accommodate  at  least  100,000  DOs  in  the  live  environment  is  given  in  Annex  C, 
and  determined  by  analysing  the  number  of  DOs  per  category  (type  of  unit)  for  a  brigade  against  brigade 
reference  exercise.  However,  the  numbers  per  category  are  not  intended  as  a  constraint  against  each 
category.  It  is  assumed  that  the  DO  IDs  are  interchangeable  across  the  categories:  only  the  grand  total  is 
relevant. 

It  is  recognised  that  when  operating  in  a  mixed  live,  virtual  and/or  constructive  environment,  the  total 
number  of  DOs  can  be  significantly  larger  than  100,000,  for  example  when  wrapping  a  live  Brigade  level 
exercise  in  the  context  of  a  virtual  or  constructive  Division  or  Corps  level  operation.  It  is  possible  that  live 
and  virtual  DOs  can  interact,  for  example  a  live  soldier  fires  at  a  virtual  target  within  a  shooting  house  or  a 
virtual  airplane  drops  a  bomb  on  a  live  vehicle. 

The  requirement  regarding  the  number  of  DOs  only  addresses  the  number  of  DOs  (be  it  live,  virtual  or 
constructive)  that  are  relevant  for  the  live  training  system  (in  this  case  relevant  means  that  a  live  DO  can 
influence  other  DOs  or  can  be  influenced  by  other  DOs). 

3.3.2  Influence  of  System  Design  on  the  Definition  of  External  Interfaces 

As  stated,  the  data  elements  from  the  defined  supersets  that  are  actually  transferred,  depend  on  the  system 
design.  To  illustrate  that  different  transfer  methods  require  different  datasets,  the  table  below  shows  a 
possible  mapping  of  a  contact  engagement  of  a  shooter  hitting  a  target  with  a  rifle  on  two  types  of  transfer 
methods:  a  transfer  method  based  on  a  one-way  line  of  sight  transfer  (e.g.,  laser)  and  a  transfer  method  based 
on  geo-pairing. 

The  data  elements  are  divided  into  three  categories: 

•  The  data  element  is  transferred  as  part  of  the  engagement  within  the  training  system  (green). 

•  The  data  element  is  not  transferred  as  part  of  the  engagement,  but  taken  into  account  by  the  training 
system  (yellow),  for  example  because  the  data  element  is  registered  by  the  affected  DO(s). 

•  The  data  element  is  not  transferred,  it  is  not  taken  into  account  by  the  training  system,  but  it  still  can 
influence  the  simulation  (red).  For  example,  in  a  simple  one-way  line  of  sight  system,  when  the 
affected  DO  receives  the  engagement  data,  the  engagement  is  considered  successful.  However,  even 
though  in  this  case  the  terrain  and  DO  locations  are  not  transferred  and  not  taken  into  account  by  the 
training  system,  the  physical  (live)  terrain  can  block  the  transfer,  thereby  influencing  the 
engagement. 

The  difference  between  these  two  methods  can  be  explained  by  the  fact  that  the  one-way  line  of  sight  method 
makes  use  of  the  characteristics  of  the  live  physical  environment,  while  the  geo-pairing  method  resembles 
more  a  virtual  simulation. 
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The  one-way  line  of  sight  method  sends  a  directional  signal  containing  the  shooter  ID  and  the  used 
ammunition  type.  This  signal  can  be  detected  by  another  DO,  which  can  determine  the  time  and  point  of 
impact  and  the  projectile  impact  velocity,  based  on  the  received  data.  Much  of  the  required  data  for  the 
engagement  is  implicit,  because  reality  “automatically”  takes  care  of  it:  if  the  weapon  is  not  directed  at  a 
target,  the  signal  will  not  reach  the  target  and  therefore  the  target  will  not  be  engaged.  A  physical  object  in 
the  terrain  can  block  the  transfer  signal,  more  or  less  simulating  the  blocking  of  a  fired  bullet. 

The  geo-pairing  method  needs  to  know  much  more  of  the  physical  environment  to  simulate  an  engagement. 
At  the  moment  of  a  shot,  the  system  must  have  available  all  relevant  characteristics  of  the  shooter 
(ID,  location,  weapon  type,  weapon  angle,  used  ammo  type)  and  that  of  all  other  DOs  (ID,  location,  velocity) 
to  determine  if  they  are  affected  or  not.  Also,  the  system  must  know  the  exact  configuration  of  the  physical 
terrain  to  determine  if  the  bullet  hits  a  target,  misses  a  target  or  is  stopped  by  a  physical  object  in  the  terrain. 

Typically  the  properties  of  the  terrain,  weapons  etc.,  are  not  transferred  at  each  shot,  but  are  loaded  into  the 
training  system  before  exercise  execution. 

3.3.3  Implementing  Interoperability 
3.3.3. 1  Levels  of  Fidelity  /  Detail  of  Simulation 

Depending  on  the  training  purposes  it  is  possible  to  simulate  the  activities  and  effects  of  non-ballistic  and 
non-line  of  sight  weapon  systems  at  different  levels  of  detail.  In  many  cases  the  most  important  objective  is 
that  the  effects  of  these  weapon  systems  can  be  simulated,  while  simulating  the  exact  activities  and 
procedures  to  achieve  those  effects  is  of  less  importance,  as  long  as  fairness  of  the  fight  can  be  ensured.  Skill 
training  is  typically  done  outside  the  scope  of  tactical  exercises. 

For  example,  there  are  several  ways  to  simulate  the  use  of  mortars  in  a  live  urban  environment: 

•  A  simple  approach  is  that  a  fire  support  request  is  issued  by  an  observer.  That  request,  sent  through 
operational  C4I  systems,  ends  up  at  a  fire  control  centre.  If  the  request  is  granted,  a  fire  support 
mission  can  be  executed  directly  from  EXCON,  not  requiring  any  action  of  actual  mortar  systems 
that  could  be  present  in  the  physical  environment. 

•  A  more  integrated  solution  could  be  that  the  order  for  the  fire  support  mission  is  sent  through  the 
operational  C4I  system  to  a  mortar  unit  in  the  physical  environment.  Once  they  are  in  position  and 
ready  to  fire  (so  involving  mortar  crews  and  taking  into  account  real  C2  procedures,  time  and 
location  parameters),  EXCON  is  notified,  who  subsequently  executes  the  fire  mission.  This 
notification  can  be  done  simply  by  radio,  but  it  can  also  be  envisioned  that  the  mortars  are  in  some 
way  instrumented,  so  that  they  can  provide  the  trigger  for  the  start  of  the  fire  mission. 

•  A  better  integrated  solution  could  be  that  the  mortars  provide  their  settings  to  the  training  system, 
including  a  trigger  when  a  mortar  grenade  is  fired,  so  that  the  actions  of  the  mortar  crew  define  the 
execution  of  the  fire  mission  in  the  training  system,  without  any  additional  action  from  EXCON. 

•  An  alternative  solution  could  be  that  the  order  for  the  fire  support  mission  is  sent  through  the 
operational  C4I  system  to  a  virtually  simulated  mortar  unit,  for  example  a  mortar  simulator. 

For  the  training  objectives  of  the  forward  observer  and  the  personnel  influenced  by  the  effects  of  the  fire 
mission,  the  first  solution  could  be  sufficient,  while  having  instrumented  fire  support  weapon  systems 
provides  additional  training  value  for  the  personnel  in  the  fire  support  chain.  In  addition,  the  manoeuvre  unit 
can  be  confronted  with  mistakes  made  by  the  fire  support  crews,  like  wrong  timing,  location  and/or 
ammunition. 
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3.3.3.2  Interoperability 

Implementing  interoperability  has  at  least  two  aspects  from  a  functional  point  of  view,  commonality  of 
models  and  adequacy  of  data  transfer: 

•  Commonality  of  Models  -  If  two  systems  have  different  types  of  models,  they  still  can  be 
interoperable,  either  by  using  only  the  greatest  common  denominator  or  by  defining  a  mapping 
between  the  models.  Take  for  example  a  system  which  uses  4  different  operational  statuses  of  DOs 
(e.g.,  operational,  mobility  kill,  fire  power  kill,  total  kill)  and  a  system  which  uses  many  more 
statuses,  having  several  stages  of  mobility  kills  (e.g.,  track  or  wheel  fallen  off,  axle  broken,  engine 
destroyed)  and  several  types  of  fire  power  kill.  It  could  be  agreed  that  when  interoperating  and 
directly  setting  the  operational  status  of  a  DO  of  the  other  system,  the  second  system  only  uses  4  of 
its  operational  statuses  (in  fact  adopting  the  model  of  the  first  system),  or  otherwise  that  a  mapping 
is  made  between  the  different  status  (e.g.,  that  all  mobility  kills  of  the  second  system  map  onto  the 
one  mobility  kill  of  the  first  system  and  that  the  mobility  kill  of  the  first  system  maps  onto  the 
mobility  kill  -  engine  destroyed  of  the  second  system).  Which  procedure  to  apply  must  be  agreed 
upon  before  operating  together. 

•  Adequacy  of  Data  Transfer  -  The  sender  must  provide  the  receiver  with  the  (minimal)  dataset  so 
the  receiver  can  perform  its  function.  What  that  dataset  is,  depends  on  how  and  where  in  the  system 
data  is  processed.  So,  for  example  in  case  of  a  direct  fire  engagement  in  a  laser  system,  the  weapon 
direction  and  angle  does  not  have  to  be  part  of  the  transferred  engagement  data  for  the  target  to 
determine  the  effect  of  the  shot,  while  in  a  geo-pairing  system  the  weapon  direction  and  angle  must 
be  part  of  the  engagement  data  for  the  system  to  determine  the  effect  on  the  target. 

3.3.4  El  -  DO  Engagement 
3.3.4.1  Types  of  Engagement 

In  the  UCATT  context  an  engagement  represents  an  action  on  a  DO.  For  the  definition  of  the  El  interface, 
different  types  of  engagements  were  examined  and  specified: 

•  Contact  and  Proximity  Engagements  -  A  contact  engagement  is  one  where  a  projectile  hits  the 
target,  e.g.,  a  bullet  or  an  anti-tank  high  explosive  round.  A  proximity  engagement  is  where  the 
ammunition  does  not  hit  a  target,  but  it  explodes  in  the  vicinity  of  a  target  and  thereby  affects  it, 
e.g.,  an  ammunition  with  a  time  or  proximity  fuse. 

•  Missile  Engagements  -  These  are  closely  related  to  contact  and  proximity  engagements,  but  the 
flight  trajectory  and  mode  of  control  require  extra  parameters. 

•  Minefield  Engagements  -  A  minefield  is  a  collection  of  mines  located  in  the  same  area.  They  can 
be  simulated  as  individual  mines,  either  physically  placed  in  the  live  environment  or  virtually 
simulated  in  the  training  system  (“EXCON”).  In  both  cases  the  interaction  with  these  mines  is  a 
contact  or  proximity  type  engagement,  covered  by  the  first  case  listed  above.  However,  there  are 
also  training  systems  that  simulate  a  minefield  as  an  area  without  simulating  each  individual  mine 
wherein  a  DO  has  a  certain  probability  of  getting  struck  by  a  mine  while  in  that  area  designated. 
Simulation  of  individual  mines  is  more  realistic  but  for  backward  compatibility  reasons  the 
implementation  of  minefields  as  probability  areas  is  taken  into  account.  This  includes  the  creation  of 
minefields,  effect  of  minefields  and  the  clearing  of  minefields. 

•  Fire  Support  Engagements  -  A  fire  support  target  area  is  the  3-dimensional  space  where  the 
ammunitions  of  a  fire  support  mission  deliver  effect.  This  covers  mortar  or  artillery  fire  or  aerial 
bombardments.  When  fire  support  is  modelled  as  (a  series  of)  individual  munitions,  the  interactions 
with  the  ammunitions  are  contact  or  proximity  engagements.  Fire  support  can  also  be  simulated 
without  simulating  each  individual  projectile  such  as  where  a  DO  has  a  certain  probability  of  getting 
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engaged  by  a  delivered  projectile.  The  implementation  of  fire  support  target  areas  as  probability 
areas  is  taken  into  account  in  the  definition  of  the  engagement  interface. 

•  CBRN  Engagements  -  A  CBRN  area  is  an  area  which  contains  a  toxic  agent  and  can  affect  DOs. 
CBRN  areas  come  in,  at  least,  two  forms: 

1)  A  contaminated  area,  which  is  static  and  sticks  to  the  ground,  infrastructure  and  other  objects;  or 

2)  A  cloud,  which  is  dynamic  and  due  to  the  influence  of  atmospheric  conditions  (wind, 
temperature,  humidity,  etc.),  changes  its  location,  shape,  size  and  density  (and  therefore  its 
effect)  over  time. 

A  CBRN  attack  can  result  in  both  a  static  contaminated  area  and  a  dynamic  cloud.  The  creation  and 
deactivation  of  CBRN  areas  and  being  affected  by  CBRN  areas  is  taken  into  account.  Also  the 
creation  and  deactivation  of  CBRN  decontamination  areas  and  the  interactions  with  DOs  is 
considered  in  the  engagement  dataset. 

•  Energy  Weapon  Engagements  -  Energy  weapons  emit  energy  and  thereby  can  influence  Dynamic 
Objects.  There  are  two  types  of  energy  weapons: 

1)  Weapons  that  emit  one  burst  of  energy,  like  for  example  a  (nuclear)  Electro  Magnetic  Pulse 
(EMP)  or  a  flash-bang  grenade,  which  generates  simultaneously  an  intense  flash  of  light  and  a 
pressure  and  strong  sound  wave.  The  interactions  with  these  types  of  weapons  can  be  modelled 
as  a  contact  or  proximity  engagements. 

2)  Weapons  that  emit  energy  for  a  certain  amount  of  time.  Typically  the  start  and  end  time  are 
under  user  control.  For  example  sound  waves  or  micro  waves  can  be  generated  by  a  weapon 
when  it  is  activated  and  the  energy  emission  stops  when  the  weapon  is  deactivated  (trigger 
released).  When  the  emission  stops,  also  the  influence  stops.  The  emission  of  this  type  of 
weapons  requires  a  new  engagement  definition.  When  energy  weapons  emit  energy  during  a 
certain  timeframe,  it  is  important  to  note  that  many  of  the  engagement  parameters  can  change 
during  the  engagement.  For  example,  the  shooter  and  target(s)  can  move,  the  direction  of  the 
weapon  can  change  and  maybe  even  the  energy  level  can  change. 

•  Non-Lethal  (or  Less  than  Lethal)  Weapon  (NLW)  Engagements  -  The  purpose  of  NLW  is  to 

temporarily  incapacitate  the  target.  So  the  major  difference  with  other  types  of  weapons  is  that  their 
effects  are  temporal;  they  do  not  require  an  explicit  repair  or  healing  or  medical  action.  There  are 
many  types  of  NLW,  however,  their  use  can  be  modelled  by  the  mechanisms  and  datasets  covered 
by  the  types  of  engagements  described  above. 

•  Jammer  Engagements  -  Jammers  are  devices  that  generate  a  “bubble”  of  electronic  noise  that 
disturbs  the  signal  by  which  a  Radio  Controlled  1ED  (RC-1ED)  is  initiated,  thereby  preventing  it 
from  detonating.  Also,  as  side  effect,  a  jammer  can  hinder  or  disturb  the  radio  communication  of 
DOs  that  are  located  in  the  generated  bubble.  The  activation,  deactivation  and  interaction  with 
jammers  are  taken  into  account  in  the  engagement  dataset. 

•  Repair  and  Medical  Activities  -  During  operations  (minor)  damages  to  vehicles  and  large  weapon 
systems  can  be  repaired  in  the  field,  either  by  the  crew  themselves  or  by  Combat  Service  Support 
units.  Similarly,  wounded  personnel  can  be  treated  in  the  field  by  other  (including  medical) 
personnel.  These  repair  and  medical  activities  greatly  influence  the  tactical  operation:  they  consume 
resources  for  execution,  they  require  protection,  they  take  time  and  the  results  of  the  activities 
influence  the  combat  power  of  a  unit.  Therefore  it  is  important  that  these  functionalities  are  taken 
into  account  in  the  specification  of  the  engagement  dataset. 

•  Logistical  (Resupply)  Activities  -  During  exercises  supplies  are  consumed  and  replenished. 
Registering  and  analysing  ammunition  consumption  and  resupply  activities  must  be  supported  by 
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the  training  system  and  are  therefore  incorporated  into  the  engagement  dataset.  Resupply  activities 
can  be  performed  by  resupply  vehicles  or  by  members  of  EXCON,  including  O/Cs  in  the  field. 

•  Imitated  Engagements  (by  Observer/Controller)  -  An  O/C  performs  many  functions  and  this  can 
include  acting  as  a  part  of  the  EXCON  function  for  administrative  purposes  with  the  affected  DO 
aware  of  this  intervention.  It  is  also  desirable  for  the  O/C  to  be  able  to  alter  the  status  of  a  DO 
directly  and  without  the  affected  DO  being  aware  of  the  O/C  intervention.  As  such  an  O/C,  acting  in 
that  EXCON  capability,  requires  the  ability  to  imitate  the  engagements  listed  above  with  appropriate 
ammunition,  etc.  If  for  regular  El  engagements  the  affected  DO  is  notified  of  the  origin  and  nature 
of  the  engagement,  the  DO  will  be  provided  with  spoof  information  as  specified  by  the  O/C. 
The  data  required  for  the  imitated  engagements  is  part  of  the  engagement  dataset. 

Urban  operations  are  not  exclusively  the  task  for  ground  based  forces,  but  are  generally  conducted  by  joint 
forces,  incorporating  aerial  and  naval  forces.  Typical  relevant  example  situations  from  the  air  domain  have 
been  analysed  in  order  to  derive  possible  additional  requirements  regarding  the  UCATT  interfaces  and 
definition  of  engagement  data:  these  appear  in  Annex  E.  It  was  concluded  that  interactions  with  aerial  and 
naval  forces  are  fully  covered  by  the  datasets  already  defined. 

3.3.4.2  Propagation  of  Engagements 

Propagation  of  an  engagement  occurs  when  one  DO  is  engaged  and  as  a  result  of  that  engagement,  the  DO 
itself  engages  one  or  more  other  DOs.  Those  subsequent  engagements  can  be  the  same  type  as  the  original 
one,  sometimes  with  altered  parameters,  or  it  can  be  different  types  of  engagements.  Typical  examples  are: 

•  A  bullet  hits  a  wall,  flies  through  it  and  hits  another  DO.  In  that  case  the  wall  initiates  a  contact 
engagement  with  the  same  ammo  type  and  depending  on  the  type  of  material  of  the  wall, 
with  different  velocity  parameters  (mainly  a  lower  speed). 

•  A  bullet  hits  a  wall,  ricochets  and  hits  another  DO.  The  wall  initiates  a  contact  engagement  with  the 
same  ammo  type  but  also  with  a  different  direction. 

•  An  explosive  grenade  hits  a  wall,  the  wall  is  destroyed  and  a  DO  nearby  is  affected  by  the  debris 
from  the  wall  and/or  blast  of  the  explosion.  Upon  destruction  the  wall  initiates  a  proximity 
engagement  with  debris  from  the  backside  of  the  wall.  It  can  also  initiate  another  proximity 
engagement  in  front  of  the  wall. 

•  An  explosive  device  (e.g.,  IED  or  hand  grenade)  explodes  in  a  room  causing  debris  (stones,  glass 
shards)  to  spread  into  the  room  or  into  the  street,  affecting  other  DOs.  One  or  more  walls  initiate 
proximity  engagements  directed  inwards  and/or  outwards. 

•  A  grenade  hits  a  vehicle  and  the  personnel  inside  is  affected  by  fragments  of  the  grenade,  fragments 
of  the  vehicle  and/or  the  blast.  The  vehicle  initiates  a  proximity  engagement  directed  inside  the 
vehicle.  DOs  outside  the  vehicle  and  in  close  proximity  of  the  impact  point  might  also  be  affected 
by  a  proximity  engagement  directed  outwards  from  the  side  of  impact.  If  the  grenade  does  not 
penetrate  the  vehicle,  DOs  standing  on  the  other  side  of  the  vehicle  will  not  be  affected. 

•  A  grenade  hits  a  vehicle,  the  vehicle  explodes  and  DOs  close  to  the  explosion  are  affected  by  the 
debris  of  the  vehicle  and/or  blast  of  the  explosion.  The  vehicle  initiates  a  proximity  engagement  in 
all  directions. 

•  A  grenade  hits  a  fiiel  storage  tank,  the  tank  explodes  and  affects  DOs  near  the  storage  tank.  In  this 
case  the  storage  tank,  modelled  as  a  DO,  initiates  a  proximity  engagement. 

•  A  grenade  hits  a  CBRN  storage  tank,  the  tank  is  damaged  and  releases  a  CBRN  cloud.  The  storage 
tank  therefore  creates  a  CBRN  area. 

•  A  vehicle  enters  a  CBRN  area  and  is  contaminated.  If  the  crew  has  not  taken  the  proper  protective 
measures,  they  will  be  contaminated  by  the  vehicle. 
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Although  not  categorised  as  a  propagation  of  engagements,  an  engagement  can  change  the  properties  and 
engagements  of  a  DO.  Examples  are: 

•  An  explosive  grenade  destroys  a  room  in  a  building.  When  subsequently  other  DOs  enter  the 
destroyed  room,  they  get  killed  themselves. 

•  A  vehicle  is  destroyed  and  is  burning.  When  other  DOs  come  too  close  to  the  burning  vehicle  or 
enter  the  vehicle,  they  can  be  affected. 

•  If  a  CBRN  contaminated  vehicle  is  not  decontaminated,  unprotected  personnel  interacting  with  the 
contaminated  vehicle,  can  also  be  contaminated.  In  effect  the  contaminated  vehicle  becomes  a  small 
CBRN  area. 

Propagation  of  engagements  can  be  intentional:  such  as  when  a  shooter  fires  ammunition  at  a  house  in  order 
to  neutralise  adversary  personnel  inside  or  unintentional  (and  thus  classified  as  collateral  damage)  such  as 
when  an  enemy  armoured  vehicle  is  destroyed  and  as  a  result  civilians  in  the  vicinity  are  wounded  as  a  result 
of  the  explosion. 

The  objective  of  considering  the  example  situations  of  propagation  of  engagements  is  to  analyse  if  additional 
engagement  mechanisms,  parameters  or  ammunition  codes  are  required.  The  conclusion  is  that  the  current 
identified  engagement  mechanisms  and  parameter  sets  are  sufficient  to  implement  propagation  of 
engagements. 

In  order  to  implement  the  situation  that  a  DO  breaks  apart  and  pieces  of  it  engage  other  DO,  a  special 
ammunition  code  for  “debris”  must  be  present.  It  is  not  required  to  further  subdivide  this  ammunition  code, 
allowing  for  example  to  differentiate  between  size  of  debris  or  type  of  material.  Such  details  go  beyond  the 
training  objectives  of  UCATT,  although  it  is  recognised  that  small  pieces  of  glass,  large  pieces  of  brick  or 
hot  pieces  of  metal  can  inflict  different  types  of  damage. 

3.3.4.3  Equipment  Pairing 

This  is  defined  as  the  situation  where  a  piece  of  equipment  that  is  not  modelled  as  a  DO,  can  be  used  by 
different  DOs  during  an  exercise,  so  it  cannot,  or  at  most  only  temporarily,  be  considered  an  integral  part  of  a 
certain  DO.  The  piece  of  equipment  has  no  status  of  its  own.  Whether  the  equipment  can  be  used  or  not  is 
derived  from  the  status  of  the  DO  that  operates  it.  So  for  example  a  rifle  can  be  passed  from  one  soldier  to 
another,  but  if  the  receiving  soldier  is  heavily  wounded,  he  cannot  fire  the  rifle. 

If  it  is  determined  to  assign  a  status  to  the  piece  of  equipment  (is  it  operational  or  not?),  then  the  equipment 
must  be  modelled  as  a  DO  and  using  the  equipment  by  one  or  more  DO  is  called  DO  association  (described 
in  the  next  section).  For  equipment  pairing  the  equipment  therefore  must  have  a  unique  ID  in  the  training 
system,  but  has  no  status  of  its  own. 

Typical  example  situations  of  equipment  pairing  are: 

•  The  soldier’s  personal  weapon. 

•  A  soldier  takes  a  weapon  from  the  rack  of  a  vehicle. 

•  A  soldier  takes  a  weapon  from  a  wounded  comrade. 

•  A  soldier  puts  on  a  CBRN  mask. 

•  A  soldier  puts  on  a  helmet. 

•  A  soldier  wears  body  armour. 

•  A  soldier  uses  electronics,  e.g.,  a  laser  target  designator. 
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•  A  soldier  uses  a  specific  training  device  to  perform  specific  interventions,  like  medical,  repairing  or 
resupply  activities. 

•  A  soldier  throws  a  hand  grenade  (the  grenade  is  not  modelled  as  a  DO).  But  for  monitoring  and 
AAR  purposes  it  is  desired  to  know  who  has  thrown  the  grenade  (e.g.,  to  identify  instances  of 
friendly  fire).  That  a  thrown  hand  grenade  can  be  picked  up  by  another  player  and  returned  has  not 
been  considered  a  requirement. 

It  must  be  possible  that  one  DO  has  multiple  equipment  pairings  simultaneously,  e.g.,  to  wear  a  helmet  and 
body  armour  at  the  same  time.  Also,  it  must  be  possible  to  distinguish  between  different  types  of  the  same 
kind  of  equipment,  for  example  different  types  of  body  armour  (to  give  different  levels  of  protection), 
different  types  of  CBRN  protective  measures,  etc.,  and  influencing  damage  calculations  appropriately. 

The  purposes  of  equipment  pairing  are  to: 

•  Register  which  DO  uses  what  (type  of)  equipment.  This  can  be  used  to  influence  the  results  of 
engagements  (for  example  body  armour  increases  protection  against  bullets)  and  for  monitoring 
purposes. 

•  Check  whether  the  operating  DO  is  able  (based  on  its  damage  state  or  functional  qualifications  or 
training)  to  use  the  equipment.  A  typical  example  of  the  latter  case  being  the  different  levels  of 
medical  personnel  where  a  Combat  Life  Saver  is  allowed  to  perform  some  basic  medical  treatments, 
while  a  doctor  is  allowed  to  perform  more  complex  medical  treatments.  It  is  up  to  the  training 
staff  to  decide  how  to  tag  the  capabilities  of  each  DO.  For  example,  it  can  be  set  individually, 
or  automatically  derived  from  the  function  profile  of  the  DO.  Also  the  extent  of  this  condition  check 
remains  a  decision  of  the  training  staff.  For  example,  it  could  be  decided  that  an  engineer  is  not 
allowed  to  fire  an  anti-tank  weapon,  because  handling  such  a  weapon  is  not  part  of  his  training  as 
engineer.  Flowever,  he  could  have  acquired  these  skills  in  a  previous  function.  Additionally,  if  an 
untrained  operator  manages  to  use  the  equipment  effectively,  even  by  sheer  coincidence,  the  effect 
is  valid,  as  it  would  be  in  reality. 

•  Check  whether  there  is  sufficient  ammunition  to  fire  the  weapon.  In  the  case  the  weapon  in  the 
training  environment  uses  physical  items  (such  as  blanks)  to  enable  the  weapon  to  fire,  the  amount 
of  these  physical  items  will  determine  the  number  of  times  a  functioning  weapon  can  fire.  Flowever, 
if  the  training  system  does  not  use  physical  items  to  determine  if  the  weapon  can  fire  or  not  (but  for 
example  uses  an  ammo  count  residing  in  the  DO),  then  the  DO  is  responsible  for  disabling  the 
weapon  to  fire  when  the  ammo  is  exhausted. 

•  As  stated,  equipment  pairing  and  also  removing  that  pairing  can  change  the  properties  of  a  DO  and 
therefore  can  influence  the  results  of  engagement.  For  example,  with  body  armour,  a  soldier  is  less 
vulnerable  to  a  hit  by  a  bullet  than  without  body  armour. 

•  Some  engagements  do  not  only  occur  at  a  specific  instance  in  time,  such  as  that  delivered  by  a 
bullet,  but  last  for  a  certain  duration  such  as  being  exposed  to  a  CBRN  area.  In  these  cases, 
removing  the  pairing  between  a  piece  of  equipment  and  a  DO  will  not  only  change  the  properties  of 
that  DO,  but  can  also  result  in  changing  its  damage  status.  For  example,  when  standing  in  a  CBRN 
area  paired  with  a  gas  mask,  a  soldier  might  be  protected  and  suffer  no  damage.  When  removing 
that  gas  mask  (and  pairing),  his  properties  change  and  the  soldier  might  become  contaminated  and 
even  wounded  or  killed.  Although  no  new  engagement  is  initiated  (the  soldier  did  not  move  into  a 
CBRN  area,  he  is  already  in  it),  removing  the  equipment  pairing  along  with  his  gas  mask,  changes 
the  characteristics  and  the  result  of  an  ongoing  engagement. 

Requirements  that  result: 

•  Transfer  the  equipment  ID  to  the  operating  DO  (and  from  there  to  EXCON).  This  allows  the 
training  system  to  register  who  uses  what  equipment.  Also  the  position  of  the  equipment  is  derived 
from  (and  equal  to)  the  position  of  the  operating  DO. 
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•  Transfer  the  operating  DO  ID  to  the  equipment.  Required  for  training  systems  where  the  equipment 
physically  implements  an  engagement,  for  example  in  laser  based  systems  a  rifle  must  transmit  the 
shooter  ID  to  the  target. 

•  Preferably  equipment  pairing  must  occur  without  requiring  special  actions  from  the  operator. 

•  For  engagements  the  equipment  pairing  must  take  place  in  near  real-time,  because  the  pairing  must 
be  in  effect  when  the  equipment  is  actually  used  (e.g.,  firing  a  weapon,  throwing  a  hand  grenade)  or 
the  operating  DO  is  engaged  (e.g.,  a  soldier  is  fired  upon  and  does  he  wear  body  armour?). 

•  For  monitoring  purposes  it  is  sufficient  when  the  pairing  is  registered  in  administrative  time 
(e.g.,  when  was  a  CBRN  mask  put  on?). 

3.3.4.4  DO  Association 

DO  association  is  defined  as  the  situation  where  two  or  more  DOs  are  logically  grouped  in  order  to,  for 
example,  synchronise  their  position  or  enable  the  propagation  of  effects,  etc.: 

•  Synchronise  the  (simulated)  position  of  the  DOs  in  case  DOs  are  physically  connected  to  one 
another  (e.g.,  persons  mounted  in  vehicle  or  aboard  a  helicopter,  persons  in  a  building).  In  this 
situation  the  need  for  DO  association  originates  from  technical  limitations,  for  example  persons 
mounting  a  vehicle  or  entering  a  building  can  lose  accuracy  or  even  the  complete  track  of  the  GPS 
or  similar  signal. 

•  Propagate  effects  in  case  DOs  are  enclosed  within,  on  or  adjacent  to  another  DO  (e.g.,  players 
mounted  in  a  vehicle,  in  a  building,  a  vehicle  on  a  bridge,  etc.).  Propagation  of  effects  is  closely 
related  to,  but  (technically)  different  from  propagation  of  engagements.  In  case  of  propagation  of 
engagements  the  engaged  DO  initiates  another  engagement  and  therefore  can  affect  other  DOs  in  its 
vicinity.  That  secondary  engagement  will  initiate  a  damage  calculation.  Propagation  of  effects  is 
setting  the  damage  status  of  one  of  more  DOs  associated  with  the  engaged  DO.  The  damage 
calculation  of  the  associated  DO(s)  is  initiated  by  the  primary  engagement.  Propagation  of 
engagements  and  propagation  of  effects  are  different  solutions/implementations  to  achieve  a  similar 
result. 

Propagation  of  effects  occurs  when  a  DO,  associated  with  other  DOs,  is  engaged  and  consequently 
the  associated  DOs  can  be  affected.  For  example  soldiers  mount  a  vehicle,  the  vehicle  is  destroyed 
and  consequently  the  soldiers  are  wounded  or  killed. 

DO  association  enables  DOs  to  benefit  or  suffer  from  the  associated  infrastructure  or  vehicle. 
An  example  of  suffering  from  an  association  is  when  a  building  is  destroyed,  soldiers  within  the 
building  are  wounded  or  killed.  An  example  of  benefitting  from  an  association  is  when  a  vehicle  is 
CBRN  protected  because  of  functioning  ventilation/overpressure  of  the  vehicle  and  the  personnel 
within  that  vehicle  does  not  need  personal  CBRN  equipment  to  be  protected  against  a  CBRN 
engagement. 

Propagation  of  effects  is  also  relevant  for  infrastructure  objects  that  are  composed  of  other  objects, 
each  modelled  as  a  DO.  For  example  a  house  can  be  made  up  of  walls,  floors,  ceilings,  doors  and 
windows.  When  each  of  these  elements  is  modelled  as  a  DO,  they  can  all  have  their  own  status. 
But  there  are  dependencies  based  on  the  composition  of  the  higher  order  object  of  infrastructure. 
For  example,  when  a  wall,  containing  a  door,  is  destroyed,  then  also  the  door  should  be  destroyed, 
even  when  the  door  itself  is  not  engaged.  When  a  house  is  made  up  of  4  walls  and  a  ceiling,  and  3  or 
more  walls  are  destroyed,  then  also  the  supported  ceiling  should  be  destroyed,  even  when  the  ceiling 
itself  is  not  engaged. 

•  Check  whether  the  operating  DO  is  able  (based  on  its  damage  state)  to  use  the  operated  equipment. 
For  example,  when  the  crew  of  a  crew-served  weapon  is  wounded,  they  will  not  be  able  to  fire  the 
weapon. 
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Typical  example  situations  of  DO  association  are: 

•  A  soldier  (DO)  mounts  an  infantry  fighting  vehicle.  When  the  vehicle  moves,  the  position  of  the 
soldier  is  derived  from  the  position  of  the  vehicle. 

•  A  soldier  (DO)  enters  a  building.  When  the  building  is  damaged,  consequently  the  soldier  can  get 
wounded  or  killed. 

•  A  tank  gunner  (modelled  as  a  DO)  mounts  a  tank  (another  DO).  When  the  vehicle  is  damaged, 
consequently  the  gunner  can  get  wounded  or  killed.  Conversely,  when  the  gunner  is  wounded, 
consequently  he  cannot  fire  the  gun  of  the  tank. 

•  A  vehicle  enters  a  building.  When  the  building  is  damaged,  consequently  the  vehicle  can  sustain 
damage. 

•  A  soldier  or  vehicle  is  on  a  bridge.  When  the  bridge  is  destroyed,  consequently  the  DOs  on  it  can  get 
killed. 

•  An  anti-tank  weapon  (modelled  as  a  DO)  is  operated  by  a  soldier.  When  the  soldier  is  wounded, 
consequently  he  cannot  fire  the  anti-tank  weapon. 

Requirements  that  result: 

•  Transfer  the  IDs  of  the  associated  DOs  amongst  each  other  and  to  EXCON. 

For  position  synchronisation  and  propagation  of  effects  this  typically  will  be  the  transfer  of  the  IDs 
of  the  smaller  DOs  to  the  larger  DO  (a  vehicle  or  building  must  know  which  DOs  it  contains  and  a 
bridge  must  know  which  DO  are  on  it,  not  the  other  way  around).  For  checking  the  ability  to  employ 
equipment,  this  is  the  transfer  of  the  operating  DO  ID  to  the  employed  DO. 

•  DO  association  must  occur  without  requiring  special  actions  from  the  involved  DOs. 

•  For  engagements  the  DO  association  must  take  place  in  near  real-time. 

•  For  monitoring  purposes  it  is  sufficient  when  the  association  is  registered  in  administrative  time. 

A  DO  can  have  multiple  associations  at  any  given  time.  For  example  a  DO  can  be  in  or  on  another  DO, 
while  being  associated  with  one  or  more  weapons.  Association  is  assumed  to  be  only  one  layer  deep, 
although  a  DO  can  be  in  more  than  one  DO  simultaneously:  a  soldier  can  be  in  a  vehicle  while  that  vehicle  is 
on  a  bridge  but  the  soldier  is  associated  only  through  the  vehicle  to  the  bridge. 

3.3.5  E4  -  DO  Reporting 

Reporting  requirements  can  be  separated  into: 

1 )  Requirements  for  exercise  control  (the  process  to  monitor  and  control  the  content  of  an  exercise  to 
achieve  the  training  or  analysis  objectives);  and 

2)  System  control  (the  process  to  monitor  and  control  the  state  of  the  training  system  to  enable  an 
exercise). 

3.3. 5.1  Exercise  Control 

An  important  element  of  exercise  control  is  monitoring  events  and  (resulting)  status  changes  of  DOs. 
Typically  the  DOs  causing  and  being  affected  by  the  event  and  the  type  of  event  must  be  reported  in  near 
real-time,  while  it  should  be  possible  to  retrieve  other  associated  parameters,  such  as  weapon  and 
ammunition  used  in  a  direct  engagement.  Also  the  data  required  to  centrally  determine  the  outcome  of 
engagements  are  part  of  E4.  The  E4  dataset  includes: 

•  Status  changes  of  a  DO  (caused  by  the  DO  itself,  events  or  by  EXCON); 
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•  Contact  and  proximity  engagements; 

•  Missile  engagements; 

•  Creation,  deactivation  and  clearing  of  minefields; 

•  Minefield  engagements; 

•  Activation  of  fire  support  target  areas; 

•  Activation,  changes  and  deactivation  of  CBRN  areas; 

•  Activation  and  deactivation  of  decontamination  areas; 

•  Energy  weapons  engagements; 

•  Jammer  activation  and  deactivation; 

•  Repair  activities; 

•  Medical  engagements;  and 

•  Logistic  engagements. 

Other  types  of  data  for  exercise  control  are: 

•  Audio  and  video  recorded  for  monitoring  (especially  Safety  monitoring)  and  including  used  relevant 
radio  channels  and  audio  recorded  from  microphones  installed  at  relevant  locations  must  be  made 
available  in  real-time. 

•  Audio  and  video  images  used  for  AAR  purposes  can  be  made  available  in  administrative  time. 

•  C41  data  must  be  made  available  in  near  real-time. 

•  Weather  data,  such  as  information  about  temperature,  light  conditions,  rain,  fog,  snow,  etc.,  required 
for  AAR  purposes  can  be  made  available  in  administrative  time. 

3.3.5.2  System  Control 

A  DO  must  report  information  regarding  its  administrative  and  technical  status,  to  enable  EXCON  and 
system  technicians  to  monitor  the  system  status,  perform  maintenance,  diagnose  malfunctions  etc.  Typical 
data  elements  include: 

•  Technical  status  of  the  training  equipment. 

•  Battery  status. 

•  BIT  (built  in  test). 

•  Radio  signal  strength  (when  applicable). 

•  Connectivity  of  system  components  (e.g.,  is  the  datalink  operational?). 

•  Cheating  signal  (e.g.,  remove  a  cable). 

The  defined  dataset  for  E4  contains  all  data  elements  that  must  be  provided  to  enable  all  functions  of 
exercise  and  system  control.  This  dataset  is  described  in  Annex  F. 

Generally  status  changes  of  a  DO  are  caused  by  external  influences,  such  as  an  engagement  from  another 
DO  (typically  involving  the  El  interface),  being  provided  with  the  results  of  centrally  adjudicated 
engagements  (involving  the  E3  interface)  or  a  direct  (reset)  action  of  an  O/C  (involving  the  E2  or  E3 
interface).  For  exercise  control  purposes  it  is  important  to  know: 

•  Of  which  DO  the  status  has  changed. 

•  What  the  new  status  of  that  DO  is. 
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•  What  the  properties  of  the  affected  DO  were  at  the  moment  of  status  change,  such  as  location  and 
speed. 

•  What  the  cause  of  the  status  change  is. 

•  If  applicable,  which  other  DO  has  caused  the  status  change. 

•  What  the  properties  of  that  DO  were  at  the  moment  of  his  engagement,  such  as  location  and  speed. 

•  Not  all  information  required  for  such  an  extensive  report  needs  to  be  transmitted  by  the  affected  DO, 
but  the  training  system  can  compose  the  report  based  on  information  from  several  resources. 
Obviously  a  DO  can  only  report  the  information  he  is  provided  with  or  that  he  controls  or  computes 
himself.  For  example,  in  case  of  a  direct  engagement,  the  shooter  DO  will  report  (through  E4)  that 
he  fires  his  main  gun,  while  standing  still  at  a  certain  location.  When  he  hits  another  DO,  the 
affected  DO  will  report  (also  through  E4)  that  he  is  engaged  by  the  shooter  DO,  hit  by  a  certain 
ammunition  and  as  a  result  has  suffered  a  mobility  kill,  while  driving  at  a  certain  location.  A  typical 
situation  for  line-of-sight  based  training  systems  is  depicted  in  Figure  3-1. 


Figure  3-1:  E4  Reporting  for  Line-of-Sight  Training  Systems. 

DO  A  fires  his  rifle  at  DO  B  (El  engagement),  who  as  a  consequence  is  killed. 

DO  A  reports  this  direct  engagement  (E4  report),  but  does  not  know  whether  he  hit  DO  B  and  what  the 
consequence  of  the  engagement  is. 

DO  B  senses  the  engagement  and  determines  the  outcome.  Subsequently  DO  B  reports  he  is  engaged  by  DO 
A  and  the  resulting  status  change  (E4  report). 

Similarly  forced  status  changes  by  E2  and  E3  are  also  reported  by  DO  B. 

A  status  change  can  also  occur  without  an  external  cause,  without  the  involvement  of  other  DOs.  Examples 
are  an  (automatic)  tampering  kill  when  the  crew  violates  certain  conditions  or  a  health  degradation  over  time 
when  a  wounded  soldier  is  not  treated. 

3.3.6  E2  -  Training  System  Status  Change 

This  interface  controls  the  technical  status  of  a  training  system  and  its  components.  Through  this  interface  it 
is  possible  that  a  DO  is  initialised,  reset,  calibrated,  etc.  This  interface  accommodates  the  distribution  of  an 
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(altered)  terrain  representation  or  damage  models  for  systems  that  require  such  data  at  decentralised  nodes. 
System  management  must  be  able  to  set  or  change  the  following  data: 

•  Turning  on  or  off  of  system  components. 

•  Configuration  of  the  system  state. 

•  Mapping  of  players  and  equipment. 

•  Creating  and  modifying  ORBATs. 

•  Loading  reference  data  such  as  terrain  database  or  damage  model. 

The  corresponding  dataset  is  described  in  Annex  G. 

3.3.7  E3  -  DO  Status  Change 

The  E3  interface  is  used  to  set  the  (simulated)  operational  status  of  a  DO,  either  as  a  direct  action  of  an  O/C 
or  from  EXCON,  to  distribute  the  outcome  of  an  engagement  that  is  centrally  evaluated  or  to  distribute 
characteristics  of  engagement  areas  and  engagement  parameters  in  order  to  determine  engagements  and/or 
outcomes  of  engagements  at  the  DO  level. 

With  direct  interactions  an  O/C  can  control  the  status  of  a  DO,  by  (re)setting  the  value  of  a  particular 
variable.  Generally  this  is  done  as  an  exercise  intervention  outside  the  tactical  training  exercise  context. 
For  example,  to  reset  a  DO  either  because  of  a  malfunction  of  the  training  equipment  or  just  to  let  him 
continue  the  fight  for  training  purposes.  If  the  affected  DO  is  notified  who  caused  the  interaction,  he  will  be 
notified  it  was  an  O/C  or  EXCON  interaction. 

For  results  of  indirect  fire  more  data  can  be  required  to  provide  to  the  affected  DO  than  just  the  new  status 
and  cause  (indirect  fire).  Information  regarding  for  example  type  of  ammunition,  distance  and  direction  with 
respect  to  the  DO  can  be  important  to  generate  the  appropriate  messages  or  effects.  Also  the  detonation 
location  can  result  in  different  types  of  explosions,  e.g.,  air  burst  versus  ground  explosions,  which  can  be 
represented  by  different  visual  representations  in  the  field,  so  the  trainees  can  learn  from  it  and  take  the 
proper  measures. 

The  requirement  to  include  full  engagement  data  sets  in  E3  is  justified  to  enable  centrally  triggered 
engagements  be  evaluated  locally  at  the  DO  level. 

The  E3  dataset  also  contains  information  on  the  definition  of  engagement  areas,  such  as  minefields, 
fire  support  target  areas  and  CBRN  areas.  The  need  for  this  requirement  depends  on  the  training  system 
design.  Three  types  of  situations  are  considered: 

•  The  engagement  areas  and  DO  interactions  with  these  areas  are  only  registered  and  managed  by 
EXCON.  EXCON  determines  the  outcome  of  the  engagement  (damage  calculation  performed  by 
EXCON)  and  only  the  results  of  an  engagement  are  provided  to  the  affected  DO.  In  this  case  a  DO 
does  not  need  to  know  about  (the  definition  of)  engagement  areas.  Information  about  engagement 
areas  is  transferred  between  training  systems  through  E8. 

•  EXCON  determines  an  engagement  of  a  DO  with  an  engagement  area  and  provides  the  DO  only 
with  the  relevant  data  to  determine  the  outcome  of  the  engagement  (damage  calculation  performed 
by  a  DO).  For  example,  when  a  DO  enters  a  minefield,  the  DO  is  provided  with  the  type  of  mine  he 
triggered,  the  DO  is  not  provided  with  the  properties  of  the  whole  minefield. 

•  The  characteristics  of  engagement  areas  are  provided  to  all  DOs,  so  each  DO  can  determine  the 
interaction  with  an  engagement  area  and  subsequently,  determine  the  outcome  of  that  engagement 
(damage  calculation  performed  by  a  DO). 
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In  the  latter  two  cases  the  infonnation  regarding  interactions  with  engagement  areas  or  regarding  the 
characteristics  of  engagement  areas  respectively,  is  provided  to  DOs  through  E3. 

The  E3  dataset  is  defined  in  Annex  H. 

3.3.8  E5  -  EXCON  Communication 

This  interface  enables  the  communication  between  training  staff  members  of  different  systems  operating  in 
the  same  exercise,  both  analogue  (typically  voice)  and  digital  communication. 

For  voice  communication  no  dataset  is  required.  Instead  an  agreement  must  be  made  on  the  frequency  to  be 
used.  Generally  there  will  be  no  requirement  to  encrypt  the  EXCON  communication,  but  if  so,  an  agreement 
must  be  made  on  the  encryption  method  to  be  used.  There  are  standards  available  to  select  from. 

Of  secondary  priority  are  the  following  requirements: 

•  Audio  recorded  for  monitoring  and  AAR  purposes.  This  includes  used  relevant  EXCON  radio 
channels  and  audio  recorded  from  microphones  installed  at  relevant  locations. 

•  Video  images  used  for  safety  reasons  must  be  made  available  in  real-time,  while  video  used  for 
AAR  purposes  can  be  made  available  in  administrative  time. 

•  Digital  data  enabling  remote  EXCON  functionality  such  as  for  example  the  current  O/C  laptop 
capability  used  in  some  systems. 

3.3.9  E6  -  Receive  C4I  Data  and  E7  -  Send  C4I  Data 

Since  1995  extensive  studies  have  been  conducted  by  NATO  and  the  MIP  (Multilateral  Interoperability 
Programme)  on  how  C41  systems  should  communicate  with  each  other  and  exchange  information  between 
them.  This  has  resulted  in  a  model  for  data  exchange,  JC3IEDM,  which  has  been  accepted  by  many 
countries.  For  a  live  simulation  system  to  read  from  and  inject  information  into  a  C4I  system  it  is 
recommended  by  UCATT  that  the  JC3IEDM  data  model  is  used  to  define  the  information  that  is  to  be 
inserted  or  read  from  the  C4I  system. 

C-BML  might  be  useful  in  case  of  a  synthetic  wrap,  when  live  DOs  provide  orders  to  simulated  units. 

It  is  recommended  that  liaison  is  established  between  the  UCATT  community  and  the  NATO  efforts 
enhancing  the  JC3IEDM  and  C-BML  standards,  in  order  to  provide  them  with  UCATT  specific  requirements. 

3.3.10  E8  -  Event  Data  Exchange 

This  interface  enables  the  exchange  of  data  between  systems,  which  can  influence  the  course  of  the  training 
session  and  generally  has  a  dynamic,  time  critical  character.  UCATT-2  recommended  use  of  DIS  or 
HLA  as  standard  for  this  external  interface.  Insights  gained  during  the  UCATT-3  timeframe  support  this 
recommendation. 

3.3.11  E9  -  DO  Association  and  Pairing 

The  E9  interface  enables  the  logical  linking  of  objects  in  the  training  environment,  this  includes  linking  of 
DOs  amongst  each  other  (DO  association)  and  linking  equipment  that  is  not  modelled  as  a  DO  with  DOs 
(equipment  pairing). 

The  dataset  for  DO  association  (and  DO  de-association)  is  a  simple  one,  it  contains  the  ID  of  the  DO  that  is 
(dis)associated  with  a  higher  level  or  containing  DO. 
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The  dataset  for  equipment  pairing  is  twofold.  Transmitted  from  a  piece  of  equipment  to  a  DO: 

•  ID  of  the  equipment. 

•  Type  of  equipment. 

Transmitted  from  a  DO  to  a  piece  of  equipment: 

•  Signal  to  disable  the  equipment  to  function,  based  on  conditions  determined  by  the  DO  (e.g.,  its 
operational  status,  capability  level  or  ammo  count). 

3.3.12  E10  -  Exchange  Platform  Data 

The  E10  interface  enables  data  exchange  between  the  training  system  and  instrumented  operational  (weapon) 
systems.  It  is  recognised  that  the  number  of  different  types  of  operational  systems  that  can  be  used  in  live 
training  exercises  is  large  and  that  each  type  of  system  probably  will  require  a  different  dataset  to  be 
exchanged  with  a  training  system,  depending  on  the  functionality  of  both  the  operational  system  and  the 
training  system.  Given  the  low  priority  of  this  interface  in  combination  with  the  huge  amount  of  work  to 
investigate  the  system  specific  requirements,  this  interface  was  not  researched  in  the  UCATT-3  timeframe. 

3.3.13  Ell  -  Reference  Data  Exchange 

This  interface  enables  the  exchange  of  data  that  is  generally  used  for  reference  purposes,  such  as  ORBAT 
definitions,  damage  model  definitions,  geospatial  (terrain)  data,  recorded  exercises,  etc. 

MSDL  seems  to  be  a  promising  candidate  as  standard  for  (a  large  part  of)  Ell.  However,  it  has  been 
observed  that  MSDL  lacks  some  information  on  physical  structures.  Therefore  it  is  recommended  that  the 
MSDL  community  should  incorporate  information  on  physical  structures  into  the  MSDL  standard. 
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A.l  TECHNICAL  ACTIVITY  PROPOSAL  (TAP) 


ACTIVITY 

REFERENCE 

NUMBER 

MSG-140 

ACTIVITY  TITLE 

URBAN  COMBAT  ADVANCED  TRAINING 
TECHNOLOGY  LIVESIM  STANDARDS 
(UCATT  LSS) 

APPROVAL 

TYPE  AND 

SERIAL  NUMBER 

RTG 

START 

2015 

LOCATION)  S)  AND  DATES 

20 1 5  Kickoff  meeting  Paris 

2015  I-ITSEC  meeting  USA,  Orlando 

20 1 6  ITEC/  spring  meeting 

2016  PDG/PSG  autumn  meeting 

2016  I-ITSEC  meeting  USA,  Orlando 

20 1 7  ITEC/  spring  meeting 

2017  PDG/PSG  autumn  meeting 

2017  I-ITSEC  meeting  USA/Orlando 

20 1 8  ITEC/  spring  meeting 

END 

2018 

COORDINATION  WITH 

OTHER  BODIES 

SISO 

NATO  CLASSIFICATION 

OF  ACTIVITY 

RELEASABLE  TO  THE  PUBLIC 

Non-NATO 

Invited 

Yes 

PUBLICATION  DATA 

TR 

UU 

KEYWORDS 

URBAN  COMBAT  ADVANCED  TRAINING  TECHNOLOGY,  UCATT, 
Live  Simulation,  Standards 

A.1.1  Background  and  Justification  (Relevance  to  NATO) 

NATO  Studies  SAS  030,  Study  on  Urban  Operations  2020  and  Land  Operations  2020  clearly  indicate  that 
Urban  Areas  are  the  most  likely  battlefield  in  the  21st  century. 

The  problems  and  limitations  associated  with  developing  the  first  generation  of  Military  Operations  on 
Urban  Terrain  (MOUT)  training  facilities  are  to  be  understood. 

A  team  of  experts  from  NATO  NAAG  completed  a  feasibility  study  in  2002  and  concluded  that  a  number  of 
potential  interoperability  areas  were  identified  and  assessed  to  be  worthy  of  further  investigation. 

MSG-032  UCATT  (2003  -  2007)  of  NMSG  started  to  identify  and  investigate  some  areas  and  reported  them 
in  their  final  report  for  the  live  domain.  A  number  of  areas  were  not  completely  covered  or  needed  more 
investigation  also  a  number  of  areas  are  new. 

The  UCATT  report  became  more  or  less  the  guideline  for  URBAN  COMBAT  TRAINING  facilities  design. 
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Also  the  first  steps  in  order  to  bring  the  defined  interface  specification  to  a  standard  (through  the  SISO) 
process  had  been  started.  MSG-063  UCATT-2  (2007  -  201 1)  the  follow  on  of  MSG-032  UCATT  displayed 
the  result  of  UCATT  work  approach  in  a  life  (technical)  demonstration  of  interoperability  between 
(modified)  existing  systems.  A  spin  off  of  the  UCATT  work  was  a  new  laser  standard  (OSAG-2)  that  is 
already  in  use  with  a  number  of  European  countries.  Goal  of  UCATT  is  that  after  SISO  approval  OSAG-2  is 
replaced  by  the  laser  implementation  of  the  UCATT  SISO  standard. 

Under  the  SISO  organisation,  a  study  group  was  formed  (UCATT  SG)  to  prepare  the  release  of  a  product 
nomination  for  the  UCATT  standard  framework. 

MSG-063  was  followed  up  by  2  new  groups:  MSG-098  (UCATT  Architecture)  and  MSG-099  (UCATT 
Standards)  (2011  -2015). 

They  were  tasked  to  refine  the  architecture  (098)  and  writing  the  first  SISO  Standard  (099).  At  the  same  time 
the  SISO  process  was  worked  through  by  writing  and  getting  approved  the  final  SISO  study  group  report. 

A  product  nomination  was  submitted  and  approved.  The  PDG  (Product  Development  Group)  was 
established.  The  first  release  of  the  UCATT  Standard  with  the  laser  implementation  was  submitted  for 
balloting. 

The  virtual  and  constructive  domain  was  explored  and  existing  (SISO)  standards  were  reviewed  as  a  result  of 
the  UCATT  architecture. 

UCATT  deliverables  to  date:  Site  register,  Research  needs,  Interoperability  specification,  functional 
architecture,  documented  life  interoperability  demonstration,  best  practices,  first  release  of  SISO  Standard 
(laser  implementation),  draft  of  player  interface-implementation  (E4). 

In  the  last  couple  of  years  UCATT  has  become  NATO’s  focal  point  for  live  training  technologies.  Beside 
that  UCATT  has  become  the  focal  point  of  information  exchange  for  the  military  user  community, 
government  procurement  and  the  leading  Industries  with  respect  to  live  training  and  simulation. 

A.1.2  Objective(s) 

Further  development  and  support  of  the  SISO  UCATT  standard.  Transfer  the  currently  used  functional 
architecture  into  the  NATO  Architectural  Framework  (NAF)  where  applicable  to  verify  the  validity  of  the 
architectural  approach  in  relation  to  physical  implementations.  Feedback  as  to  the  effectiveness  of  the 
physical  implementation  solutions  will  be  given  from  the  groups  military  experts  with  respect  to  the  existing 
Use  Cases.  Identify,  maintain  and  improve  a  suitable  architecture  and  a  standard  set  of  interfaces  that  enable 
interoperability  of  live  training  and  simulation  components  covering  the  urban  aspects  that  does  not  inhibit 
future  research  and  enhancements. 

Validate  the  applicability  of  existing  standards  for  interfacing  to  the  simulation  environment.  Further  develop 
the  SISO  UCATT  standard  (PDG)  in  accordance  with  the  Product  Nomination  (PN)  and  maintain  the 
Standard  as  a  Product  Support  Group  (PSG). 

Maintain  function  as  focal  point  for  live  training  and  simulation  technologies  and  standards. 

A.1.3  Topics  to  be  Covered 

Operational  Concepts:  continuous  maintenance  of  the  comprehensive  list  of  developed  Generic  User 
Requirements  in  conjunction  with  NATO  Training  Groups  and  Military  Users  on  the  live,  virtual  and  the 
constructive  domain. 
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Further  standardisation  through  the  SISO  process  of  UCATT  defined  and  prioritised  interfaces  following  the 
functional  architecture.  Maintain  the  UCATT  functional  architecture  for  live  training  and  simulation. 

Establishment  of  a  PSG  to  maintain  the  UCATT  Standards. 

A.1.4  Deliverables  (e.g.,  Model,  Database, ...)  and/or  End  Products 

•  Technical  Report. 

•  SISO  Standard(s). 

A.1.5  Technical  Team  Leader  and  Lead  Nation 

Lead  Nation:  Germany. 

Points  of  Contact:  Chair:  Mr.  Armin  THINNES,  Germany  (arminthinnes@bundeswehr.org, 

+49  261  400  5234) 

Deputy  Chair:  Mr.  Ingo  W1TTWER,  Germany  (ingo.wittwer@ruag.com, 

+49  4103  939  580) 

A.1.6  Nations  Willing/Invited  to  Participate 

NATO  Nations  and  Bodies:  All  NATO  Nations  and  Bodies  invited. 

PfP  Nations:  All  PfP  nations  invited. 

Industries:  All  relevant  industries  are  invited. 

Global  Partners:  Australia,  Japan,  South  Korea  and  New  Zealand  invited. 

The  following  Nations  willing  to  participate:  Germany,  Great  Britain,  Netherlands,  France,  Sweden,  United 
States  of  America,  Austria  and  Switzerland. 

The  following  Industries  are  willing  to  participate:  Cubic  Defence  systems  (USA/NZL),  SAAB  AB  (SWE), 
Thales  Training  and  simulation  (FRA),  Airbus  Group  (FRA),  GDI  Simulation  (FRA),  RUAG  (DEU/CHE) 
and  Rheinmetall  Defence  (DEU). 

A.1.7  National  and/or  NATO  Resources  Needed  (Physical  and  Non-Physical  Assets) 

Personnel  resources  (technicaPscientific  and  military)  are  to  be  provided  through  national  contributions. 

Travel  costs  are  to  be  provided  through  national  contributions. 

SISO  membership  fees  for  NATO  and  PfP  representatives,  support  for  meeting-facilities  and  PR-material  if 
applicable. 

A.1.8  CSO  Resources  Needed  (e.g.,  Consultant  Lunding) 

Standard  support  for  STO  Task  Groups  in  accordance  with  the  current  edition  of  the  STO  Operating 
Procedures. 
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A. 2  TERMS  OF  REFERENCE 

A.2.1  Origin 
A.2.1.1  Background 

NATO  Studies  SAS  030,  Study  on  Urban  Operations  2020  and  Land  Operations  2020  clearly  indicate  that 
Urban  Areas  are  the  most  likely  battlefield  in  the  21st  century. 

The  problems  and  limitations  associated  with  developing  the  first  generation  of  Military  Operations  on 
Urban  Terrain  (MOUT)  training  facilities  are  to  be  understood. 

A  team  of  experts  from  NATO  NAAG  completed  a  feasibility  study  in  2002  and  concluded  that  a  number  of 
potential  interoperability  areas  were  identified  and  assessed  to  be  worthy  of  further  investigation. 

MSG-032  UCATT  (2003  -  2007)  of  NMSG  started  to  identify  and  investigate  some  areas  and  reported  them 
in  their  final  report  for  the  live  domain.  A  number  of  areas  were  not  completely  covered  or  needed  more 
investigation  also  a  number  of  areas  are  new. 

The  UCATT  report  became  more  or  less  the  guideline  for  URBAN  COMBAT  TRAINING  facilities  design. 

Also  the  first  steps  in  order  to  bring  the  defined  interface  specification  to  a  standard  (through  the  S1SO) 
process  had  been  started.  MSG-063  UCATT-2  (2007  -  2011)  the  follow  on  of  MSG-032  UCATT  displayed 
the  result  of  UCATT  work  approach  in  a  life  (technical)  demonstration  of  interoperability  between 
(modified)  existing  systems.  A  spin  off  of  the  UCATT  work  was  a  new  laser  standard  (OSAG-2)  that  is 
already  in  use  with  a  number  of  European  countries.  Goal  of  UCATT  is  that  after  S1SO  approval  OSAG-2  is 
replaced  by  the  laser  implementation  of  the  UCATT  S1SO  standard. 

Under  the  SISO  organisation,  a  study  group  was  formed  (UCATT  SG)  to  prepare  the  release  of  a  product 
nomination  for  the  UCATT  standard  framework. 

MSG-063  was  followed  up  by  2  new  groups:  MSG-098  (UCATT  Architecture)  and  MSG-099  (UCATT 
Standards)  (2011  -2015). 

They  were  tasked  to  refine  the  architecture  (098)  and  writing  the  first  SISO  Standard  (099).  At  the  same  time 
the  SISO  process  was  worked  through  by  writing  and  getting  approved  the  final  SISO  study  group  report. 

A  product  nomination  was  submitted  and  approved.  The  PDG  (Product  Development  Group)  was 
established.  The  first  release  of  the  UCATT  Standard  with  the  laser  implementation  was  submitted  for 
balloting. 

The  virtual  and  constructive  domain  was  explored  and  existing  (SISO)  standards  were  reviewed  as  a  result  of 
the  UCATT  architecture. 

UCATT  deliverables  to  date:  Site  register,  Research  needs,  Interoperability  specification,  functional 
architecture,  documented  life  interoperability  demonstration,  best  practices,  first  release  of  SISO  Standard 
(laser  implementation,  draft  of  player  interface-implementation  (E4). 

In  the  last  couple  of  years  UCATT  has  become  NATO’s  focal  point  for  live  training  technologies.  Beside 
that  UCATT  has  become  the  focal  point  of  information  exchange  for  the  military  user  community, 
government  procurement  and  the  leading  Industries  with  respect  to  live  training  and  simulation. 
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A.2.1.2  Justification  (Relevance  for  NATO) 

•  Maintenance  of  comprehensive  list  of  Generic  Harmonised  (between  Nations)  User  Requirements  in 
conjunction  with  NATO  Training  Groups  and  Military  Users  on  the  live,  virtual  and  the  constructive 
domain. 

•  SISO  standardised  LIVE  simulation  and  training  interoperability  interfaces  to  cope  with  the  defined  Use 
Cases  enabling  international  interoperable  training. 

•  Extension  of  the  live  functional  architecture  for  LIVE  training  according  to  new  Use  Cases. 

A.2.2  Objectives 

Further  development  and  support  of  the  SISO  UCATT-standard.  Transfer  the  currently  used  functional 
architecture  into  the  NATO  Architectural  framework  (NAF)  where  applicable  to  verify  the  validity  of  the 
architectural  approach  in  relation  to  physical  implementations.  Feedback  as  to  the  effectiveness  of  the 
physical  implementation  solutions  will  be  given  from  the  groups  military  experts  with  respect  to  the  existing 
Use  Cases.  Identify,  maintain  and  improve  a  suitable  architecture  and  a  standard  set  of  interfaces  that  enable 
interoperability  of  LIVE  training  and  simulation  components  covering  the  urban  aspects  that  does  not  inhibit 
future  research  and  enhancements. 

Validate  the  applicability  of  existing  standards  for  interfacing  to  the  simulation  environment.  Further  develop 
the  SISO  UCATT  standard  (PDG)  in  accordance  with  the  Product  Nomination  (PN)  and  maintain  the 
Standard  as  a  Product  Support  Group  (PSG). 

Maintain  function  as  focal  point  for  live  training  and  simulation  technologies  and  standards. 

A.2.3  Resources 
A.2.3.1  Membership 

Members  should  be  specialists  in  the  field  of  live  simulation  and  training  from  the  contributing  NATO 
nations  and  other  NMSG’s  associated  members. 

Three  face-to-face  meetings  per  year  are  planned.  Between  the  personal  meetings  work  is  planned  to  be 
carried  out  using  Internet.  Appropriate  collaboration  mechanisms  will  be  used  as  support  tools  (Mailing- 
Lists,  Website,  Sharepoint,  etc.). 

Lead  Nation:  Germany. 

Points  of  Contact:  Mr.  Armin  THINNES  (arminthinnes@bundeswehr.org) 

Mr.  Ingo  WITTWER  (ingo.wittwer@ruag.com) 

Nations  willing/invited  to  participate: 

•  Willing:  Germany,  Netherlands,  United  Kingdom,  United  States,  France,  Sweden,  Switzerland,  and 
Austria. 

•  Invited:  All  NATO  and  PfP  Nations,  Global  Partners. 

Industries  willing/invited  to  participate: 

•  Cubic  Defence  systems  (USA/NZL),  SAAB  AB  (SWE),  Thales  Training  and  simulation  (FRA), 
Airbus  Group  (FRA),  GDI  Simulation  (FRA),  RUAG  (DEU/CHE)  and  Rheinmetall  Defence 
(DEU). 

•  Invited:  All  relevant  simulation  industries. 
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A.2.3.2  National  and/or  NATO  Resources  Needed 

•  Personnel  resources  (technical/scientific  and  military)  are  to  be  provided  through  national  contributions. 

•  Travel  costs  are  to  be  provided  through  national  contributions. 

•  S1SO  membership  fees  for  NATO  and  PfP  representatives,  support  for  meeting-facilities  and 
PR-material,  if  applicable. 

A.2.3.3  CSO  Resources  Needed 

•  Standard  support  for  STO  Task  Groups  in  accordance  with  the  current  edition  of  the  STO  Operating 
Procedures. 

A.2.4  Security  Classification  Level 

The  activity  and  the  deliverables  are  classified  as  “RELEASABLE  TO  THE  PUBLIC”  (UU). 

A.2.5  Participation  by  Partner  Nations 

PfP  Nations:  All  PfP  nations  invited. 

Global  Partners:  Australia,  Japan,  South  Korea  and  New  Zealand  invited. 

A.2.6  Liaison 

•  S1SO  (coordination  with  UCATT  PDG  standardisation  activities). 
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To  investigate  the  interoperability  aspects  of  this  exercise,  the  UCATT  functional  architecture  is  taken  as 
reference  to  describe  to  what  extent  the  different  systems  were  able  to  exchange  data  and  through  which 
interfaces. 


B.l  El -LASER ENGAGEMENT 

In  regard  to  the  laser  interface  for  engagements  all  systems  were  already  interoperable  on  the  physical 
level,  using  the  same  laser  properties  (class,  power,  wavelength,  etc.).  Therefore  this  interface  was  used 
successfully.  For  laser  coding,  the  picture  was  as  follows: 

•  NACMTC  used  OSAG  2.0  Standard. 

•  MCTC  can  use  both  OSAG  2.0  Standard  and  Basic. 

•  DNK  vehicle  equipment  uses  OSAG  2.0  Basic. 

•  DEU  AGDUS  uses  OSAG  2.0  Basic. 

This  meant  that  OSAG  2.0  Basic  was  the  lowest  common  denominator  and  most  logical  choice  for  this 
interface.  NACMTC  did  not  support  OSAG  2.0  Basic,  but  was  given  the  ability  to  switch  between  Basic  and 
Standard  like  MCTC.  Finally,  the  standard  ammunition  tables  belonging  to  OSAG  2  were  used  to  achieve 
full  interoperability. 


B.2  E2  -  CONTROL  SYSTEM  STATUS  AND  E4  -  REPORT  STATUS 

The  E2  and  E4  interfaces  rely  on  the  long-range  radio  (LRR)  infrastructure  network.  That  means  that  the 
host  system,  in  this  case  NACMTC,  dictates  how  that  infrastructure  looks  like.  NACMTC  uses  the  Saab 
proprietary  DAN  network,  revision  5,  and  the  PDU  2. 1C  Long  Range  Radio  Data  Protocol.  Coincidently, 
MCTC  and  DNK  used  the  same,  which  provided  interoperability,  so  these  interfaces  were  used  successfully. 

For  the  NOBLE  LEDGER  exercise,  the  coverage  NACMTC  could  provide  with  its  mostly  static  and  single 
portable  base  station  was  not  enough  for  a  Brigade  level  exercise.  To  enlarge  the  coverage  area,  MCTC 
provided  6  additional  portable  base  stations  and  Saab  Sweden  provided  an  additional  two.  Germany  brought 
non-instrumented  AGDUS  for  this  exercise,  which  meant  their  equipment  had  no  radio  to  connect  to  any 
infrastructure.  As  a  work-around  for  this  challenge,  MCTC  vests  were  strapped  onto  German  combat 
vehicles  to  serve  as  a  blue-force  tracker.  This  ensured  EXCON  could  have  a  complete  operational  picture  as 
far  as  units  and  vehicles  were  concerned.  German  dismounted  troops  were  not  visible,  which  meant  they  had 
to  be  umpired  during  battle  by  O/Cs. 


B.3  E3  -  CONTROL  DO  STATUS 

The  E3  interface  relies  on  the  same  long-range  radio  infrastructure  network  as  E2  and  E4.  As  mentioned 
above,  the  ability  to  exchange  data  between  EXCON  and  players  was  already  achieved  there.  The  E3 
interface  however,  is  mainly  used  to  transfer  artillery,  CBRN  and  Engineering  effects  like  minefields.  This 
means  the  radio  commands  triggering  those  types  of  engagements  would  have  to  be  standardised. 
NACMTC,  MCTC  and  the  Danish  vehicle  equipment  all  used  the  IUC  released  AWES  2.0  Basic  simulation 
guideline  to  ensure  interoperability. 
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B.4  E5  -  EXCON  COMMS 

This  interface  is  more  commonly  referred  to  as  the  O/C  voice  network,  even  though  it  is  also  used  for  data 
transmissions  between  EXCON  and  the  O/Cs  in  the  field  and  between  O/Cs  directly.  The  O/C  voice  network 
uses  standard  analogue  FM  radio  technology,  where  every  different  system  has  its  own  fixed  frequency 
range.  Unfortunately  none  of  these  ranges  overlapped,  which  meant  there  was  no  communication  possible 
between  O/Cs  from  different  nationalities.  A  big  factor  here,  determining  native  frequency  ranges,  is  national 
frequency  management  regulations. 


B.5  E6  -  C4I  TO  EXCON  AND  E7  -  EXCON  TO  C4I 

Out  of  this  composition  of  systems,  only  MCTC  possesses  the  ability  to  exchange  data  with  C41  systems  like 
BMS  (Battlefield  Management  System),  and  only  in  the  direction  of  EXCON  (E6).  This  interface  is  used  to 
log  BMS  data  to  be  used  for  AAR  purposes.  C4I  systems  are  a  very  scattered  field  today  and  most  countries, 
mostly  for  reasons  of  operational  security,  choose  to  build  their  own  software  and  architectures.  Even  though 
standards  like  JC31EDM  exist,  interoperability  between  C4I  systems  is  still  fairly  difficult  to  achieve. 
Therefore,  BMS  systems  are  not  often  used  during  multinational  exercises,  as  not  all  information  can  reach 
all  participating  units.  This  was  the  case  for  NOBLE  LEDGER  as  well  and  therefore  this  interface  was 
disregarded. 


B.6  E8  -  EXCON  TO  EXTERNAL  SYSTEMS 

This  interface  was  not  necessary  to  be  used  for  this  exercise,  as  it  is  used  to  connect  for  instance  MCTC  and 
GUZ  Altmark  (see  Section  1.3.1). 

B.7  E9  -  REPORT  STATUS  TO  SENSE 

This  interface  allows  the  soldier  to  pair  with  his  weapon,  a  building  or  vehicle  and  works  through  Short 
Range  Radio  (SRR).  In  a  multinational  interoperability  sense,  it  should  allow  a  soldier  using  a  vest  from 
system  A  to  pair  with  and  use  a  weapon  instrumented  by  system  B.  Even  though  this  interface  was  not  tested 
during  NOBLE  LEDGER,  it  is  very  likely  interoperability  could  have  been  achieved  here  among  at  least 
the  Dutch,  Norwegian  and  Danish  troops.  These  systems  all  use  the  Saab  proprietary,  IUC  published, 
WLN  protocol. 


B.8  E10  -  PLATFORM  MANAGEMENT 

The  usage  of  this  interface  implies  the  instrumentation  of  a  combat  vehicle  from  country  A  (e.g.,  CV90  or 
Marder)  with  instrumentation  from  a  system  owned  by  country  B.  This  was  not  foreseen  and  did  not  take 
place  during  NOBLE  LEDGER  and  it  would  have  been  very  unlikely  to  succeed.  The  interfaces  between 
real-life  vehicles  and  live  simulation  systems  are  custom  built,  in  close  cooperation  with  the  vehicles 
manufacturer.  A  big  factor  standing  in  the  way  of  interoperability  here  is  both  operational  and  commercial 
security  and  a  3ld  party  will  not  quickly  get  access  to  a  vehicles’  internal  network. 

B.9  Ell  -  MANAGE  DATA  TO  STORE  DATA 

The  Ell  interface  can  be  used  for  a  lot  of  different  types  of  initialisation  data,  but  is  most  commonly  used  for 
ORBAT  data.  This  data  is  needed  to  associate  equipment  with  persons,  units  and  vehicles,  which  in  the  end 
allows  for  a  logical  picture  of  events  during  AAR.  For  the  Saab  systems  involved  during  NOBLE  LEDGER 
they  are  natively  fed  into  the  system  in  the  same  way.  The  German  AGDUS  is  excluded  here,  since  it  does 
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not  communicate  with  any  EXCON.  The  ORBAT  is  normally  created  in  an  Excel  file  and  after  conversion  to 
.XML  transferred  to  the  system  through  a  simple  USB  drive.  The  only  thing  needed  to  standardise  input  is  to 
create  an  Excel  template  that  all  countries  use,  which  is  exactly  what  was  done  for  NOBLE  LEDGER  to 
avoid  manual  input.  Therefore  this  interface  was  considered  used  successfully. 


Table  B-1 :  Summary  of  Results. 


Interface 

Result 

El-  Laser  engagement 

SUCCESSFUL 

E2  -  Control  system  status 

SUCCESSFUL 

E3  -  Control  DO  status 

SUCCESSFUL 

E4  -  Report  status 

SUCCESSFUL 

E5  -  EXCON  Comms 

UNSUCCESSFUL 

E6  -  C4I  to  EXCON  and  E7  -  EXCON  to  C4I 

NOT  USED 

E8  -  EXCON  to  External  systems 

NOT  USED 

E9  -  Report  Status  to  Sense 

NOT  USED,  PLAUSIBLE  COMPATIBILITY 

E10  -  Platform  management 

NOT  USED,  HIGHLY  UNLIKELY 

El  1  -  Manage  data  to  Store  data 

SUCCESSFUL 
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This  annex  contains  the  calculations  that  are  the  basis  for  considering  the  maximum  number  of  DOs  (player 
IDs)  for  use  in  Live  Simulation  Systems.  They  are  not  to  be  considered  definitive  or  exact,  partly  because 
different  nations  have  different  composition  of  forces.  However,  the  assumption  is  made,  that  even  though 
compositions  differ,  the  order  of  magnitude  are  similar.  The  calculations  are  based  on  the  unit  type  regarded 
to  have  the  most  number  of  entities:  the  Mechanised  (Infantry)  Unit.  The  numbers  stated  in  the  tables  below 
per  category  are  an  indication,  not  a  constraint  for  that  particular  category. 


Table  C-1:  Maximum  DO  Numbers  Calculation. 
Armoured  Infantry  Group 


Unit 

Personnel 

Weapon 

Platforms 

Personal/Group 

Weapons 

Other 

Group 

10 

1 

30 

20 

Cumulative 

0 

DOs  per  level 

61 

•  •• 

Armoured  Infantry  Platoon 

Unit 

Personnel 

Weapon 

Personal/Group 

Other 

Platforms 

Weapons 

Cumulative  (4  inf  gps) 

244 

DOs  per  level 

244 

I 

Armoured  Infantry  Company 

Unit 

Personnel 

Weapon 

Personal/Group 

Other 

Platforms 

Weapons 

Coy  staff 

15 

5 

50 

20 

Mortar  gp 

10 

3 

20 

20 

Transport  level  -1  (4  inf  platoons) 

976 

DOs  per  level 

1,119 

II 

Armoured  Infantry  Battalion 

Unit 

Personnel 

Weapon 

Personal/Group 

Other 

Platforms 

Weapons 

Battalion  staff 

40 

20 

80 

40 

Recce  platoon 

40 

8 

120 

80 

AT  platoon 

18 

6 

36 

40 

Transport  lvl  -1  (3  inf  coy’s) 

3,357 

DOs  per  level 

3,885 
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II  Tank  Battalion 


Unit 

Personnel 

Weapon 

Personal/Group 

Other 

Platforms 

Weapons 

Battalion  staff 

40 

20 

80 

40 

Tank  squadron  (x3) 

210 

50 

420 

420 

DOs  per  level 

1,280 

X  Mechanised  Brigade  and  Added  Enablers 


Unit 

Personnel 

Weapon 

Platforms 

Personal/Group 

Weapons 

Other 

Brigade  staff 

150 

30 

300 

300 

Engineer  Construction  Battalion 

550 

100 

1,500 

1,000 

Armoured  Engineer  Battalion 

550 

100 

1,500 

1,000 

Artillery  Battery 

200 

8 

400 

400 

Air  Defence  Artillery 

450 

50 

900 

200 

Logistic  Support  Det  (LSD) 

900 

100 

1,830 

400 

Transport  lvl  -1  (2  Inf  Battalions) 

7,770 

Transport  lvl  -1  (2  Tk  Battalion) 

2,560 

DOs  per  level 

24,908 

~ 

Other  Units  and  Entities 

Unit 

Civilian  population 

1,000 

Infrastructure  (structures,  bridges) 

5,000 

Minefields  (individual  mines) 

10,000 

Fire  support  units  (navy,  air  force) 

1,000 

UAS/UGS 

1,000 

Other  (sensors) 

1,000 

Recce  squadron 

6,000 

DOs  per  level 

25,000 

Total  number  of  DOs  for  one  Mechanised  Brigade,  incl.  instrumented 

infrastructure  49,908 

Total  number  of  unique  identifying  numbers,  based  on  a  Bde  on  Bde  exercise  100,000 
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One  of  the  defining  properties  of  a  DO  is  that  it  has  a  status  and  that  that  status  can  change  (generally  as  a 
result  of  engagements).  The  most  simple  set  of  statuses  consists  of  “dead”  and  “alive”.  It  is  recognised  that 
some  systems  have  a  more  elaborate  or  detailed  set  of  statuses  for  DO  than  other  systems,  most  likely 
because  there  are  specific  engagements  related  to  those  statuses.  For  example,  when  enabling  several  types 
of  medical  treatment  engagements,  the  set  of  statuses  must  be  more  advanced  than  only  “dead”  or  “alive”  to 
be  useful. 

Although  from  a  technical  point  of  view  it  is  not  required  that  training  systems  use  the  same  DO  statuses, 
interoperability  among  training  systems  is  facilitated  when  the  used  DO  statuses  are  comparable  and 
standardised.  To  accommodate  this  standardisation,  UCATT  describes  several  levels  of  DO  statuses. 
The  logical  starting  point  to  define  sets  of  DO  statuses  would  be  the  commonly  used  statuses  in  current 
training  systems.  Such  a  list  would  look  like  the  one  presented  in  Table  D-l. 


Table  D-1:  Overview  of  Commonly  Used  DO  Statuses. 


DO  Status 

Description 

Operational 

The  DO  can  use  all  its  capabilities 

Hit,  no  damage/effect 

The  DO  was  engaged  and  hit,  but  no  loss  of  capability  was 
assessed 

Miss 

The  DO  was  engaged,  but  not  hit 

Mobility  Kill 

The  DO  cannot  change  its  location  by  itself 

Weapon  Kill 

The  DO  cannot  use  its  weapon(s) 

Communications  Kill 

The  DO  cannot  use  its  communication  equipment 

Sight/sensor  Kill 

The  DO  cannot  use  its  sensors 

Payload  Kill 

The  cargo  of  the  DO  is  destroyed 

Total  Kill 

The  DO  cannot  use  any  of  its  capabilities 

Tampering  Kill 

The  DO  cannot  use  any  of  its  capabilities.  Assigned  by  the 
system  when  the  trainee(s)  violate(s)  certain  conditions 

Administrative  Kill 

The  DO  cannot  use  any  of  its  capabilities.  Assigned  by  an 

O/C  or  through  EXCON 

This  set  of  DO  statuses  is  imbalanced  because  it  contains  three  types  of  information: 

1)  The  (loss  of)  capabilities  of  the  DO.  This  category  of  information  consists  of  “Operational”, 
“Weapon  Kill”,  “Communications  Kill”,  “Sight/sensor  Kill”,  “Payload  Kill”  and  “Total  Kill”. 

2)  Information  about  engagements  on  the  DO  that  did  not  result  in  a  DO  status  change.  These  are  “Hit, 
no  damage/effect”  and  “Miss”. 

3)  The  reason  or  cause  of  a  DO  status  change.  These  are  “Tampering  Kill”  and  “Administrative  Kill”, 
where  it  is  assumed  that  the  “Total  Kill”  is  the  result  of  a  proper  engagement  in  the  training  context. 

UCATT  considers  only  the  first  type  of  information,  concerning  the  capabilities  of  a  DO,  relevant  to  be 
reflected  in  the  DO  status. 
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There  is  no  need  for  “Hit,  no  damage/effect”  and  “Miss”  as  DO  status.  In  terms  of  DO  capabilities  they  are 
the  same  as  “Operational”.  The  training  system  must  still  be  able  to  register  all  engagements  and  their 
results,  also  when  the  engagement  was  not  effective,  but  other  mechanisms  must  be  used  to  register  and 
retrieve  that  information  (call  it  “engagement  status”).  So  EXCON  must  still  be  able  to  see  that  a  shooter 
(nearly)  missed  a  target.  And  for  example  a  vehicle  being  hit,  but  not  damaged,  should  still  be  able  to 
generate  an  audio  cue  for  its  crew  to  notify  them  they  are  under  fire. 

There  is  no  need  to  reflect  in  the  DO  status  the  reason  or  cause  of  that  change,  so  there  is  no  need  for 
“Tampering  Kill”  and  “Administrative  Kill”.  In  terms  of  DO  status  they  are  the  same  as  “Total  Kill”. 
However,  the  training  system  must  still  be  able  to  register  the  cause  of  a  DO  status  change,  but  other 
mechanisms  must  be  used  to  register  and  retrieve  that  information.  It  is  recognised  that  interference  by  an 
O/C  is  a  special  cause,  but  there  are  also  not  special  statuses  for  “Killed  by  a  direct  hit”  or  “Killed  by  a 
mine”. 

At  a  lower  level  of  damage  statuses  there  is  found  a  fourth  type  of  information:  one  that  deals  with 
controlling  the  visual  representation  of  a  specific  damage.  Examples  of  these  statuses  are  “Mobility  kill 
visual”  and  “Weapon  kill  visual”  in  order  to  display  certain  signals  in  the  training  environment,  indicating  a 
DO  has  lost  its  ability  to  move  or  fire,  respectively.  It  is  not  denied  that  there  should  be  no  difference 
between  a  (visually)  undetectable  mobility  kill  and  a  visible  mobility  kill,  but  the  damage  status  is  not  the 
proper  mechanism  to  specify  this. 

A  “Tampering  kill”  is  assigned  to  a  DO  when  the  training  system  detects  that  a  trainee  violates  certain 
exercise  rules  that  can  be  classified  as  cheating.  A  typical  example  is  taking  out  the  batteries  of  his 
instrumentation  kit  so  he  will  be  invulnerable.  There  might  be  other  conditions  that  can  also  be  considered  as 
cheating,  but  one  has  to  be  careful  for  exceptions.  For  example,  moving  while  having  sustained  a  mobility 
kill  can  be  considered  as  cheating.  But  for  safety  (non-exercise  related)  reasons  it  might  sometimes  be 
necessary  to  step  out  of  harm’s  way.  Or  what  if  a  vehicle  is  towed  away  for  repair? 

The  DO  statuses  are  categorised  in  levels  (see  later).  In  addition,  DO  statuses  are  defined  for  three  types  of 
DO,  namely: 

1)  Vehicles  (in  the  broadest  sense,  it  includes  weapon  systems,  aircraft  and  naval  vessels); 

2)  Personnel;  and 

3)  Infrastructure. 

This  distinction  is  relevant  because  different  status  terminology  is  used  for  these  types  of  DO,  even  though 
the  effect  is  similar  (for  example,  a  vehicle  is  damaged,  while  a  person  is  wounded).  Technically  speaking  a 
person  can  have  a  mobility  kill,  fire  power  kill  etc.,  but  UCATT  has  respected  the  historically  adopted 
terminology  of  categories  of  “wounded”  (these  categories  can  be  mapped  onto  the  capabilities  of  a  soldier 
which  are  comparable  to  those  of  vehicles).  Despite  the  differences  in  terminology,  the  logic  behind  the 
levels  and  categories  are  the  same:  there  are  three  main  statuses  (fully  operational,  degraded  performance, 
fully  disabled)  and  each  level  is  a  further  detailing  of  the  previous  level.  At  the  first  and  second  level  the 
statuses  each  imply  a  different  loss  of  capabilities  of  the  DO.  At  the  third  level  and  below  no  different  types 
of  capability  loss  are  defined,  but  the  statuses  contain  a  more  detailed  specification  of  a  certain  type  of 
capability  loss,  mainly  used  to  enable  repair  or  medical  activities.  For  example,  the  third  level  vehicle 
statuses  “Track/wheel  fallen  off’  and  “Engine  kill”  both  inhibit  a  vehicle  to  move  and  are  two  different 
instances  of  the  second  level  “Mobility  kill”. 

A  DO  can  also  have  multiple  statuses,  except  for  “Operational”  (any  other  status  overrules  this  status)  and 
“Total  kill”  (this  status  overrules  all  other  statuses). 

Two  remarks  must  be  made  regarding  the  status  of  a  crewed  vehicle  modelled  as  a  DO. 


D  -  2 


STO-TR-MSG-098 


ANNEX  D  -  DO  STATUS  DEFINITION 


First,  a  crewed  vehicle  is  in  fact  a  combination  of  several  DOs,  namely  the  vehicle  and  each  of  its  crew. 
Consequently,  the  vehicle  and  each  crewmember  will  have  their  own  status.  All  combinations  of  statuses  are 
possible,  but  two  extremities  will  be  commented  on.  It  is  possible  that  the  vehicle  is  destroyed  (total  kill), 
while  all  its  crew  members  are  still  alive  and  operational.  This  can  for  example  be  the  case  when  the  vehicle 
is  struck  by  an  EMP,  destroying  the  vehicle’s  electronic  systems  but  not  harming  the  crew  or  when  the  crew 
were  not  in  the  vehicle  when  it  was  destroyed.  The  reverse  is  also  possible,  that  all  crewmembers  are  killed, 
but  the  vehicle  has  sustained  no  damage.  This  can  for  example  be  the  case  when  the  vehicle  enters  a  CBRN 
area  and  the  crew  has  not  taken  the  proper  protective  measures.  This  will  kill  the  crew,  but  will  not  damage 
the  vehicle.  Because  the  crew  is  dead,  the  vehicle  capabilities  are  of  no  use.  Some  would  argue  therefore  that 
the  vehicle  should  have  a  total  kill  as  well,  but  this  would  be  incorrect.  For  in  theory  a  new  crew  with 
protective  clothing  can  use  the  vehicle  and  operate  it  in  its  current  state  (which  therefore  must  be 
operational).  Using  this  logic,  there  is  no  need  for  a  status  “CBRN  kill”  as  can  be  encountered  in  some 
systems.  A  CBRN  attack  can  result  in  a  contamination  of  the  vehicle  and  disabling  or  killing  the  crew. 

A  second  remark  addresses  the  fact  that  in  some  implementations  of  training  systems  the  crew  or  other 
occupants  of  a  vehicle  are  not  modelled  as  DOs.  They  are  considered  as  an  integral  part  of  the  vehicle  and 
therefore  there  is  only  one  DO  (the  vehicle).  This  does  not  reflect  reality  perfectly,  but  cost  considerations 
will  have  played  a  major  role  in  this  decision.  To  be  able  to  model  the  situation  were  the  crew  and  vehicle 
can  have  distinct  statuses  (as  described  above,  such  as  relevant  for  CBRN  engagements),  separate  statuses 
must  be  defined.  For  example  a  status  “Crew  killed”  or  at  a  more  detailed  level  “Commander  killed”. 
For  crewmembers  not  modelled  as  DOs  it  is  not  useful  to  assign  them  statuses  regarding  the  severity,  type  or 
location  of  wounds  because  they  because  they  cannot  be  treated  like  personnel  that  is  modelled  as  DO. 

For  detailed  medical  diagnosis  and  treatment  of  personnel  the  training  system  could  simulate  data  like 
(simulated)  heartbeat,  blood  pressure,  consciousness  etc.  Although  from  a  medical  point  of  view  this  data 
(call  it  symptoms?)  would  be  seen  as  part  of  the  status  of  the  wounded  DO,  this  type  of  data  has  no  tactical 
relevance  and  therefore  will  not  be  reflected  in  the  DO  status.  On  a  practical  note  is  apparent  that  the  number 
of  statuses  would  be  very  high!  As  a  note  it  is  observed  that  in  some  current  training  systems  this  data  about 
symptoms  is  simulated  by  the  medical  DO  instead  of  the  wounded  DO. 


D.l  DAMAGE  STATUS  CATEGORIES 

Damage  statuses  are  defined  for  three  different  categories  of  DO.  For  each  category  of  DO,  different  levels 
of  interoperability  are  defined,  where  each  subsequent  level  can  contain  more  detailed  status  information. 

Table  D-2  lists  the  damage  statuses  of  (crewed)  weapon  systems  and  contains  4  levels  of  interoperability: 

•  Level  1  concerns  the  primary  functions  of  entities:  move,  engage,  communicate,  observe  and 
perform  logistics. 

•  Level  2  concerns  useful  secondary  functions  of  entities. 

•  Level  3  concerns  maintenance  and  repair  activities. 

•  Level  4  concerns  details  regarding  C41SR  systems. 

Table  D-3  lists  the  damage  statuses  of  personnel  and  contains  3  levels  of  interoperability. 

•  Level  1  concerns  the  primary  functions  of  an  individual  (move,  communicate,  engage). 

•  Level  2  differentiates  between  injured  body  parts,  resulting  in  the  (dis)ability  to  use  them. 

•  Level  3  concerns  more  advanced  injury  information  for  medical  treatment. 

Table  D-4  lists  the  damage  statuses  of  infrastructural  objects  and  contains  2  levels  of  interoperability: 
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•  Level  1  provides  the  primary  function  of  infrastructure  to  the  training  audience  (e.g.,  a  wall  provides 
cover  and/or  protection,  a  bridge  can  enable  personnel  and  vehicles  to  cross  a  gap). 

•  Level  2  provides  degraded  functions  of  infrastructure  to  the  training  audience. 


Table  D-2:  Damage  Statuses  of  (Manned)  Weapon  Systems. 


Damage  State 

Level  1 

Level  2 

Level  3 

Level  4 

Description 

Operational 

0 

0 

0 

0 

CBRNe  crew  Kill 

0.1 

0.1.0 

0.1.0.0 

Crew  killed,  but  vehicle  is 
operational,  can  be 
recovered  by  a  new  crew 

CBRNe  contaminated 

0.2 

0.2.0 

0.2. 0.0 

Vehicle  is  contaminated, 
but  still  operational,  can 
be  recovered  by 
decontamination 

Hit,  no  damage/effect 

1 

1.0 

1.0.0 

1.0.0.0 

Target  was  engaged  and 
hit,  but  no  damage  was 
assessed 

Miss 

2 

2.0 

2.0.0 

2. 0.0.0 

Target  was  engaged  but 
not  hit  (could  result  in  an 
audio  cue  for  the  crew) 

Near  miss 

2.1 

2.1.0 

2. 1.0.0 

Far  miss 

2.2 

2.2.0 

2.2.0.0 

Mobility  kill 

3 

3.0 

3.0.0 

3. 0.0.0 

Target  cannot  move 
location 

Engine  kill 

3.0.1 

3. 0.1.0 

Track/wheel  fallen  off/kill 

3.0.2 

3. 0.2.0 

Mobility  kill  visual 

3.1 

3.1.0 

3. 1.0.0 

Observable  mobility  kill 

Weapon  kill 

4 

4.0 

4.0.0 

4.0. 0.0 

All  weapons  inoperative 

Main  gun  kill 

4.1 

4.1.0 

4.1. 0.0 

Weapon  <x>  kill 

4.1.<x> 

4. 1  .<x> 

Kill  of  a  specific  weapon 
system  of  the  vehicle  (can 
be  up  to  1 00) 

Secondary  weapon  kill 

4.2 

4.2.0 

4.2. 0.0 

Definition  of  what  the 
secondary  weapon  is, 
depends  on  the  type  of 
vehicle 

Missile  weapon  kill 

4.3 

4.3.0 

4.3. 0.0 

Valid  when  the  vehicle 
has  a  missile  firing 
system 

Turret  drive  kill 

4.4 

4.4.0 

4.4.0. 0 

The  turret  of  the  vehicle 
cannot  rotate 
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Damage  State 

Level  1 

Level  2 

Level  3 

Level  4 

Description 

Ammunition  kill 

4.5 

4.5.0 

4.5. 0.0 

Automatic  ammo  load  off 

4.5.1 

4.5. 1.0 

Ammo  turret  storage  kill 

4.5.2 

4.5.2. 0 

Ammo  hull  storage  kill 

4.5.3 

4.5. 3.0 

LRF  kill 

4.6 

4.6.0 

4.6. 0.0 

Weapon  kill  visual 

4.7 

4.7.0 

4.7. 0.0 

Observable  that  all 
weapons  are  inoperative 

C41SR  kill 

5 

5.0 

5.0.0 

5. 0.0.0 

C4I  functionality  not 
available 

Communications  kill 

5.1 

5.1.0 

5. 1.0.0 

Loss  of  (voice  and  data) 
communication 

Voice  comms  damage/kill 

5.1.1 

5.1. 1.0 

Voice  comms  kill 

5.1. 1.1 

Voice  comms  degraded 

5.1. 1.2 

Data  comms  damage/kill 

5.1.2 

5. 1.2.0 

Data  comms  kill 

5. 1.2.1 

Data  comms  degraded 

5. 1.2.2 

Data  comms  corrupted 

5. 1.2.3 

BMS  computer  kill 

5.2 

5.2.0 

5.2.0.0 

Sight/sensor  kill 

5.3 

5.3.0 

5.3.0.0 

Contains  all  different  kind 
of  sensors,  optical,  radar 
etc.  that  enable  it  to 
perform  its  primary 
function 

Primary  sight  kill 

5.3.1 

5.3. 1.0 

Secondary  sight  kill 

5.3.2 

5. 3.2.0 

Auxiliary  sight  kill 

5.3.3 

5.3.3.0 

IFF  kill 

5.3.4 

5. 3.4.0 

Payload  kill 

6 

6.0 

6.0.0 

6.0.0.0 

Destruction  of  the  cargo 
of  the  vehicle 

Total  kill 

7 

7.0 

7.0.0 

7. 0.0.0 

Catastrophic  kill 

Crew  affected 

7.1 

7.1.0 

7. 1.0.0 

Relevant  for  occupants 
not  being  DOs  (DOs  have 
their  own  status) 

Crew  member  <x>  killed 

7.1.<x> 

7.1.<x> 

Relevant  for  occupants 
not  being  DOs 

Crew  member  <x>  injured 

7.2. <x> 

7.2.<x> 

Relevant  for  occupants 
not  being  DOs 
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Damage  State 

Level  1 

Level  2 

Level  3 

Level  4 

Description 

Tampering  kill 

8 

8.0 

8.0.0 

8. 0.0.0 

Automatic  kill  when  the 
crew  violates  certain 
conditions 

Administrative  kill 

9 

9.0 

9.0.0 

9. 0.0.0 

Killed  by  an  OC  or 
through  EXCON 
administrative  kill 

Table  D-3:  Damage  Statuses  of  Personnel. 


Damage  State 

Level  1 

Level  2 

Level  3 

Move 

Fire 

Communicate 

Operational 

0 

0 

0 

YES 

YES 

YES 

CBRNe  contaminated 

0.1 

0.1.0 

YES 

YES 

YES 

Hit  No  Damage/effect 

1 

1.0 

1.0.0 

YES 

YES 

YES 

Incapacitated/stunned 

1.1 

1.1.0 

NO 

NO 

NO 

Miss 

2 

2.0 

2.0.0 

YES 

YES 

YES 

Far  Miss 

2.1 

2.1.0 

YES 

YES 

YES 

Near  Miss 

2.2 

2.2.0 

YES 

YES 

YES 

Wounded 

3 

3.0 

3.0.0 

NO 

NO 

YES 

Head 

3.1 

3.1.0 

NO 

NO 

NO 

Bleeding 

3.1.1 

NO 

NO 

NO 

Blast 

3.1.2 

NO 

NO 

NO 

Bum 

3.1.3 

NO 

NO 

NO 

Chest 

3.2 

3.2.0 

NO 

NO 

NO 

Bleeding 

3.2.1 

NO 

NO 

NO 

Blast 

3.2.2 

NO 

NO 

NO 

Bum 

3.2.3 

NO 

NO 

NO 

Torso 

3.3 

3.3.0 

NO 

NO 

NO 

Bleeding 

3.3.1 

NO 

NO 

NO 

Blast 

3.3.2 

NO 

NO 

NO 

Bum 

3.3.3 

NO 

NO 

NO 

Stomach 

3.4 

3.4.0 

NO 

NO 

NO 

Bleeding 

3.4.1 

NO 

NO 

NO 

Blast 

3.4.2 

NO 

NO 

NO 

Bum 

3.4.3 

NO 

NO 

NO 
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Damage  State 

Level  1 

Level  2 

Level  3 

Move 

Fire 

Communicate 

Left  arm 

3.5 

3.5.0 

YES 

NO 

YES 

Bleeding 

3.5.1 

YES 

NO 

YES 

Blast 

3.5.2 

YES 

NO 

YES 

Bum 

3.5.3 

YES 

NO 

YES 

Broken 

3.5.4 

YES 

NO 

YES 

Right  arm 

3.6 

3.6.0 

YES 

NO 

YES 

Bleeding 

3.6.1 

YES 

NO 

YES 

Blast 

3.6.2 

YES 

NO 

YES 

Bum 

3.6.3 

YES 

NO 

YES 

Broken 

3.6.4 

YES 

NO 

YES 

Left  leg 

3.7 

3.7.0 

NO 

YES 

YES 

Bleeding 

3.7.1 

NO 

YES 

YES 

Blast 

3.7.2 

NO 

YES 

YES 

Bum 

3.7.3 

NO 

YES 

YES 

Broken 

3.7.4 

NO 

YES 

YES 

Right  leg 

3.8 

3.8.0 

NO 

YES 

YES 

Bleeding 

3.8.1 

NO 

YES 

YES 

Blast 

3.8.2 

NO 

YES 

YES 

Bum 

3.8.3 

NO 

YES 

YES 

Broken 

3.8.4 

NO 

YES 

YES 

C41SR  kill 

4 

4.0 

4.0.0 

YES 

YES 

NO 

Communications  Kill 

4.1 

4.1.0 

YES 

YES 

NO 

Voice  comms  damage/kill 

4.1.1 

YES 

YES 

NO 

Voice  comms  kill 

YES 

YES 

NO 

Voice  comms  degraded 

YES 

YES 

NO 

Data  comms  damage/kill 

4.1.2 

YES 

YES 

NO 

Data  comms  kill 

YES 

YES 

NO 

Data  comms  degraded 

YES 

YES 

NO 

Data  comms  corrupted 

YES 

YES 

NO 

BMS  computer  kill 

4.2 

4.2.0 

YES 

YES 

NO 

Sensor  kill 

4.3 

4.3.0 

YES 

YES 

NO 

STO-TR-MSG-098 


D  -7 


ANNEX  D  -  DO  STATUS  DEFINITION 


organization 


Damage  State 

Level  1 

Level  2 

Level  3 

Move 

Fire 

Communicate 

Kill 

5 

5.0 

5.0.0 

NO 

NO 

NO 

Administrative  kill 

6 

6.0 

6.0.0 

NO 

NO 

NO 

Tampering  kill 

7 

7.0 

7.0.0 

NO 

NO 

NO 

Table  D-4:  Damage  Statuses  of  Infrastructural  Objects. 


Damage  State 

Level  1 

Level  2 

Description 

Undamaged 

0 

0 

Door/window  open 

0.1 

Door/window  closed,  not  bolted 

0.2 

Door/window  closed,  simulated  bolted 

0.3 

Door/window  bolted  and  barred 

0.4 

Hit,  no  damage/effect 

1 

1.0 

Structure  was  engaged  (could  result  in 
an  audio  cue  for  the  occupants  of  the 
structure) 

Miss 

2 

2.0 

Structure  was  engaged  but  not  hit 
(could  result  in  an  audio  cue  for  the 
occupants  of  the  structure) 

Near  Miss 

2.1 

Far  Miss 

2.2 

Damaged 

3 

3.0 

Destroyed 

4 

4.0 

CBRNe  Kill 

For  example,  a  structure  could  protect 
against  fluids,  but  not  against  gasses 

Payload  Kill 

5 

5.0 

Destruction  of  the  content  of  a 
structure,  e.g.,  supplies 

Tampering  Kill 

6 

6.0 

Automatical  destruction  when  trainees 
violate  certain  conditions 

Administrative  Kill 

7 

7.0 

Destroyed  by  an  OC  or  through 

EXCON  administrative  kill 

The  statuses  “Hit,  no  damage/effect”  and  “Miss”  are  in  fact  only  temporary  (transitory)  statuses  as  a  result  of 
an  engagement  and  in  terms  of  capabilities  they  are  the  same  as  “operational”.  However  they  are  listed  in  the 
table  for  backward  compatibility  with  existing  systems. 

Also,  the  statuses  “Tampering  Kill”  and  “Administrative  Kill”  are  in  terms  of  capabilities  the  same  as 
“Total  kill”,  but  listed  in  the  table  for  backward  compatibility  with  existing  systems. 

The  treatments  for  infrastructure  are  different  than  those  of  personnel  and  vehicles  due  to  the  different 
nature.  For  example,  infrastructure  is  not  mobile  and  cannot  communicate.  However,  it  can  engage  other 
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DOs,  but  generally  in  response  to  being  engaged  itself  (as  a  medium  for  the  propagation  of  an  engagement) 
such  as  when  a  wall  that  is  hit  and  as  a  consequence  it  disperses  debris,  or  when  a  person  enters  a  CBRN 
contaminated  room  and  consequently  gets  CBRN  contaminated  himself,  or  a  person  steps  on  a  destroyed 
floor  and  consequently  he  gets  wounded  or  killed. 

Infrastructural  objects  do  have  other  capabilities  though,  depending  on  the  type  of  infrastructure.  From  a 
tactical  training  point  of  view,  a  wall  provides  cover  (protection)  for  DOs  positioned  behind.  In  reality  a  wall 
also  provides  concealment  (hiding  from  detection),  but  this  capability  is  yet  difficult  to  influence  in  a  live 
training  environment  (unless  a  see-through  property  is  implemented).  A  ceiling  provides  top  cover,  but  also 
supports  other  DOs  to  stand  and  move  or  take  up  fire  positions  on  it.  A  door  generally  does  not  provide  any 
cover,  but  allows  access  through  a  wall  (when  opened,  or  hinders  it  when  closed  or  blocked.  And  so,  many 
other  examples  can  be  given. 

The  statuses  of  infrastructural  objects  must  be  related  to  their  capabilities.  The  first  level  statuses 
“Operational”  and  “Destroyed”  are  straightforward:  the  capabilities  are  fully  available  or  not  existent 
anymore.  As  opposed  to  personnel  and  vehicles,  the  status  “Damaged”  does  not  mean  that  a  subset  of  its 
capabilities  is  not  available  anymore  (e.g.  not  able  to  move  or  fire  or  both),  but  that  the  performance  of  one 
capability  is  degraded.  For  example  a  damaged  wall  will  not  provide  protection  anymore  against  heavy 
calibre  ammunitions,  but  only  against  small  calibre  ammunitions.  As  another  example  one  could  define  that 
a  damaged  bridge  will  not  support  vehicles  of  60  tons  anymore,  but  only  vehicles  of  30  tons  or  less. 
In  addition  to  degraded  performance,  infrastructure  can  also  be  reinforced,  resulting  in  improved 
performance. 

A  solution  to  deal  with  the  complexity  of  the  statuses  of  infrastructure  at  the  lower  levels  has  two 
dimensions,  namely  categories  and  meaning. 

1)  Categories: 

a)  It  is  possible  to  define  a  specific  set  of  statuses  for  each  type  of  infrastructure  and  relate 
those  statuses  to  degrees  of  degradation  of  the  associated  capability  or  capabilities. 

b)  As  an  alternative,  the  first  level  status  “Damaged”  can  be  decomposed  into  several  statuses 
at  level  two  denoting  a  certain  percentage  of  the  remaining  capability  or  capabilities. 
Advantage  is  that  these  statuses  are  applicable  to  all  types  of  infrastructure. 

2)  Meaning: 

a)  The  operational  consequences  of  each  status  are  clearly  defined  and  standardised  among  the 
different  training  systems. 

b)  The  operational  consequences  of  each  status  are  left  to  the  responsibility  of  each  training 
system. 

From  a  standardisation  point  of  view  the  first  option  is  preferred,  but  this  requires  common  practice  and 
understanding  from  the  nations,  which  does  not  yet  exist.  The  disadvantage  of  the  second  option  is  that  when 
two  or  more  training  systems  have  assigned  a  different  meaning  to  a  certain  status,  this  could  lead  to 
confusion  and  even  negative  training  value  for  the  trainees.  For  example,  if  50%  damage  in  system  A  means 
protection  against  a  certain  type  of  ammunition,  while  in  system  B  it  means  no  protection  against  that  type  of 
ammunition. 

Because  infrastructure  generally  belongs  to  a  training  site  and  it  is  highly  unlikely  that  visiting  trainees  will 
bring  their  own  infrastructure  (as  opposed  to  personnel  and  weapon  systems),  the  infrastructure  in  one 
training  location  will  be  managed  by  one  training  system  and  thus  only  one  definition  of  infrastructure 
statuses  will  apply.  That  definition  might  be  different  than  what  the  visiting  trainees  are  accustomed  to. 
In  that  case  clear  communication  and  coordination  before  the  start  of  the  training  is  required  to  avoid 
misinterpretation. 
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Different  infrastructural  objects  (each  modelled  as  DO)  can  make  up  a  higher  order  infrastructural  object, 
the  typical  example  being  walls,  a  floor  and  a  ceiling  making  up  a  room.  And  several  rooms  grouped 
together  make  up  a  house.  In  many  cases  the  engagements  or  effects  of  the  higher  order  object  are  those 
generated  by  its  subordinate  objects.  For  example,  entering  a  destroyed  room  can  result  in  a  total  kill, 
because  the  floor  of  that  room  is  destroyed  and  causes  to  kill  the  DO  stepping  on  it. 

However,  there  are  example  situations  when  the  higher  order  object  needs  a  status  of  its  own  and  must  be 
able  to  engage  other  DOs  by  itself  and  thus  be  modelled  as  a  DO.  An  example  is  that  a  room  is  declared  out 
of  bounds,  while  the  room  is  not  destroyed. 

From  a  standardisation  point  of  view,  the  damage  statuses  of  infrastructural  objects  are  the  least  important. 
Given  the  UCATT  functional  architecture,  it  is  assumed  that  engagements  and  associations  involving 
infrastructure  are  handled  by  those  infrastructural  DOs  or  the  host  training  system.  So  unless  one  brings 
one’s  own  infrastructural  objects  to  training  system,  these  damage  statuses  must  be  standardised  or 
harmonised. 


D.2  GENERAL  REMARK 

It  is  only  useful  to  define  statuses  for  DOs  when  each  status  can  be  represented  in  the  training  environment, 
either  visually  (light,  smoke,  sound,  etc.)  or  that  the  status  can  be  retrieved  for  the  DO  in  a  way  that 
resembles  reality  (e.g.  medical  diagnosis  requires  the  medic  to  make  physical  contact  with  the  wounded 
person). 
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E.l  INTRODUCTION 

This  annex  describes  the  data  elements  that  are  required  to  simulate  an  engagement.  In  the  UCATT  context 
an  engagement  represents  an  action  on  a  dynamic  object.  Examples  are: 

•  Direct  or  indirect  fire  from  a  shooter  to  a  target. 

•  An  1ED  explosion  affecting  dynamic  objects  in  its  influence  sphere. 

•  Medical  treatment  of  a  medic  on  a  wounded  person. 

•  A  repair  action  by  a  maintenance  engineer  on  a  damaged  vehicle. 

•  An  O/C  action  on  a  Dynamic  Object  (DO). 

In  the  tables  below  the  superset  of  data  elements  for  several  types  of  engagement  is  defined. 

The  tables  contain  different  columns  defined  as: 

1 )  Parameter:  This  is  a  data  element  required  to  simulate  an  engagement. 

2)  Purpose:  The  reason  the  data  element  is  required.  Several  categories  are  used: 

a)  TARGETING:  The  data  is  used  to  determine  which  and  where  dynamic  object(s)  is  or  are 
affected  by  the  engagement. 

b)  DAMAGE  CALCULATION:  The  data  is  used  to  detennine  the  outcome  of  the  engagement. 

c)  MONITORING:  The  data  is  used  for  on-line  monitoring  of  the  execution  of  the  exercise  and 
system  performance  and  for  After  Action  Review,  the  evaluation  and  feedback  of  the 
performance  towards  the  Training  Audience  (TA). 

d)  ANALYSIS:  The  data  is  used  for  other  purposes,  e.g.,  statistical  or  trend  analysis,  not  directly 
used  for  monitoring  or  feedback  towards  the  TA. 

3)  Unit:  The  unit  in  which  the  data  element  is  expressed,  e.g.,  distance  or  location  in  meters,  time  in 
seconds.  When  the  data  is  a  system  internal  identifier,  it  is  expressed  as  dynamic  object  ID  or 
category. 

4)  Max:  The  maximum  value  of  the  data  element. 

5)  Accuracy:  The  required  accuracy  of  the  data  element,  expressed  in  (sub-)  units.  This  means  that  the 
actual  value  of  the  data  element  must  be  expressed  in  multiples  of  the  mentioned  accuracy. 


E.2  CONTACT  AND  PROXIMITY  ENGAGEMENTS 

Table  E-l  contains  the  data  for  contact  and  proximity  engagements.  A  contact  engagement  is  an  engagement 
where  a  projectile  hits  the  target,  e.g.,  a  bullet  or  an  anti-tank  high  explosive  round.  A  proximity  engagement 
is  an  engagement  where  the  ammunition  does  not  hit  a  target,  but  it  explodes  in  the  vicinity  of  a  target  and 
thereby  affects  it,  e.g.,  an  ammunition  with  a  time  or  proximity  fuse. 
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Table  E-1:  Superset  of  Data  for  Contact  and  Proximity  Engagements. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Shooter  ID 

MONITORING 

ID 

100,000 

- 

Shooter  location  (x,  y,  z), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub-decimeter 

Shooter  velocity  (vector), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

Weapon  type 

TARGETING 

MONITORING 

Category 

- 

Weapon  ID 

ANALYSIS 

ID 

100 

- 

Shooter  weapon  mode 

TARGETING 

MONITORING 

Category 

- 

Weapon  direction/angle 
(vector),  plus  accuracy  indicator 

TARGETING 

VERY  HIGH 

Ammunition  type 

DAMAGE 

CALCULATION 

MONITORING 

Category 

Fuse  type 

TARGETING 

MONITORING 

Category 

- 

Fuse  settings 

TARGETING 

MONITORING 

- 

Engagement  range 

DAMAGE 

CALCULATION 

MONITORING 

Meter 

Meter 

Detonation  location  (x,  y,  z), 
plus  accuracy  indicator 

DAMAGE 

CALCULATION 

MONITORING 

Meter 

Sub-decimeter 

Effect  direction/angle  (vector) 
at  the  moment  of  detonation 

DAMAGE 

CALCULATION 

MONITORING 

HIGH 

Projectile  impact  velocity 
(vector),  plus  accuracy  indicator 

DAMAGE 

CALCULATION 

Meter/sec 

As  required 

Effect  volume 

DAMAGE 

CALCULATION 

MONITORING 

Meter 

Meter 

Terrain 

TARGETING 

DAMAGE 

CALCULATION 

Meter 

Sub-decimeter 

Atmospheric  data 

TARGETING 

- 

Affected  DO(s)  ID 

DAMAGE 

CALCULATION 

MONITORING 

ID 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Affected  DO(s)  location  (x,  y, 
z),  plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub-decimeter 

Affected  DO(s)  velocity 
(vector),  plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

Time  of  start  of  the  engagement 
(trigger  time),  plus  accuracy 
indicator 

TARGETING 

MONITORING 

Seconds 

Micro-second 

Time  of  end  of  the  engagement 
(impact  time),  plus  accuracy 
indicator 

TARGETING 

MONITORING 

Seconds 

Micro-second 

Point  of  impact 

DAMAGE 

CALCULATION 

Meter 

Sub-decimeter 

The  properties  of  the  target  are  also  very  important  to  calculate  the  results  of  the  engagement.  Properties 
such  as  its  current  operational  status  (damaged  or  not),  its  level  of  protection  (wearing  body  armour  or  NBC 
mask),  etc.  However,  this  is  not  part  of  the  engagement.  The  engagement  ends  when  it  affects  the  target. 
The  engagement  function  will  trigger  another  function,  which  determines  the  effect(s)  of  the  engagement. 


General  Remark  about  Locations,  Velocities  and  Angles 

For  some  (types  of)  engagement  a  high  accuracy  of  the  locations,  velocities  and  angles  of  the  involved 
Dynamic  Objects  is  required  to  determine  the  results  of  the  engagement.  For  example,  a  difference  of 
1  degree  of  the  direction  of  the  firing  weapon  can  be  the  difference  between  a  hit  or  a  miss.  Also,  in  the 
confined  spaces  of  the  urban  environment,  soldiers  can  be  very  close  to  each  other  or  can  take  cover  behind  a 
pillar  or  other  (small)  object.  In  the  simulation  environment  an  engagement  must  affect  only  those  dynamic 
objects  that  would  be  affected  in  reality.  Thus,  for  example,  a  bullet  from  a  small  arms  weapon  has  only  a 
very  small  area  of  effect,  therefore  the  flight  path  and  point  of  impact  require  a  high  level  of  accuracy. 
On  the  other  hand,  when  using  weapons  or  ammunitions  with  a  large  area  effect,  a  (far)  lesser  level  of 
accuracy  is  required.  Therefore,  for  each  of  these  types  of  data  element,  an  indicator  of  accuracy  is  required, 
to  identify  the  accuracy  of  the  supplied  data  and  determine  the  (fidelity)  of  the  engagement  results. 


Shooter  ID 

The  unique  identifier  to  identify  the  Dynamic  Object  that  causes  the  engagement.  It  is  assumed  that  based  on 
this  ID  the  characteristics  of  this  DO  can  be  retrieved,  such  as  the  type  (e.g.,  tank  or  infantry)  or  the  name  of 
the  player  or  crew  members.  Three  example  situations  can  be  distinguished: 

•  The  weapon  used  in  the  engagement  is  an  integral  part  of  a  DO  and  has  no  DO  ID  of  itself,  e.g.,  the 
main  gun  of  a  tank.  The  shooter  ID  in  this  example  is  the  ID  of  the  tank. 

•  The  weapon  used  is  not  an  integral  part  of  the  DO,  but  can  be  used  by  other  DOs  during  the  same 
exercise,  and  the  weapon  is  not  modelled  as  a  DO.  This  is  called  equipment  pairing  (see  main 
document  Section  3. 3.4.3).  A  typical  example  is  a  rifle  that  can  be  handed  over  to  another  soldier. 
The  shooter  ID  in  this  example  is  the  ID  of  the  soldier,  not  of  the  rifle. 

•  The  weapon  used  is  modelled  as  a  DO  itself  and  (therefore)  can  be  used  by  other  DOs  during  an 
exercise.  A  typical  example  is  a  crew-served  machine  gun  operated  by  two  soldiers.  The  shooter  ID 
in  this  example  is  the  ID  of  the  machinegun,  not  of  (one  of)  the  soldiers  who  operate  the  gun. 
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The  identity  of  the  soldiers  can  be  retrieved  through  DO  association  (see  main  document  Section 
3. 3.4.4). 

Shooter  Location  (x,  y,  z) 

The  three-dimensional  position  of  the  shooter  at  the  start  of  the  engagement. 


Shooter  Velocity  (Vector) 

The  three-dimensional  speed  of  the  shooter  at  the  start  of  the  engagement.  This  is  for  example  required  for 
targeting  purposes,  to  determine  the  correct  lead  angle.  It  can  also  be  used  for  monitoring  purposes  when 
training  skills  of  crews  of  moving  (stabilised  or  non-stabilised)  weapon  systems. 


Weapon  Type 

The  type  of  the  weapon  that  is  used  to  execute  the  engagement,  such  as  launching  the  ammunition. 
For  example  an  M-16  assault  rifle  or  a  120  mm  gun  of  a  main  battle  tank.  It  is  used  mainly  for  monitoring 
purposes,  because  the  effects  of  the  engagement  are  not  determined  by  the  weapon  type,  but  by  the 
properties  of  the  ammunition  at  the  point  of  impact. 


Weapon  ID 

When  a  weapon  is  an  integral  part  of  a  DO  (such  as  a  coax  machine  gun  on  a  tank  or  the  different  weapon 
systems  on  a  naval  vessel),  this  parameter  identifies  the  weapon  that  was  used  in  the  engagement,  relative  to 
the  Shooter  ID.  Land  based  systems  generally  have  only  a  few  weapons,  but  a  battleship  can  have  dozens  of 
weapons  installed  on  it,  therefore  the  maximum  value  is  set  to  100. 


Shooter  Weapon  Mode 

The  mode  of  the  weapon  at  the  moment  of  engagement.  It  contains  for  example  the  settings  of  a  fire  control 
computer,  the  used  sighting  device  etc.  It  is  used  for  correct  targeting  and  monitoring  purposes  when  training 
gunnery  skills. 


Weapon  Direction/ Angle 

The  direction/angle  of  the  weapon  at  the  moment  of  engagement,  used  for  targeting,  calculation  of  the 
trajectory  of  the  fired  ammunition.  Because  of  this  function,  the  accuracy  of  this  parameter  needs  to  be  very 
high. 


Ammunition  Type 

The  type  of  the  used  ammunition,  mainly  used  for  damage  calculation  (can  also  be  used  for  determining  the 
trajectory  of  the  projectile)  and  monitoring  purposes. 


Fuse  Type 

The  type  of  fuse  used  for  an  ammunition.  For  certain  ammunition  types  the  operator  can  select  the  type  of 
fuse,  for  example  applicable  to  the  “Bunkerfaust”,  artillery  and  mortar  rounds,  HE  kinetic  rounds,  etc. 
This  determines  whether  the  detonation  of  the  ammunition  is  triggered  by  for  example  physical  contact, 
time,  a  sensor  (e.g.,  heat  signature,  radar  signature,  laser  pointed)  or  a  combination  of  triggers.  The  type  of 
fuse  determines  the  point  of  detonation  and  thus  is  used  for  targeting. 
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Fuse  Settings 

Depending  on  the  type  of  fuse,  certain  settings  can  be  applied.  For  example  a  time  triggered  fuse  needs  a 
specified  time  or  delay  after  impact  to  detonate,  while  other  fuses  need  a  specified  time  after  firing  to 
become  active  (e.g.,  to  allow  a  proximity  fuse  to  be  shot  through  foliage).  The  parameter  is  used  for  targeting. 


Engagement  Range 

The  distance  over  which  a  target  is  engaged,  ft  is  used  for  monitoring  purposes  but  it  can  also  be  used  for 
damage  calculation,  to  take  the  effective  range  of  the  ammunition  into  account,  to  prevent  that  a  weapon 
affects  targets  beyond  its  effective  range  (e.g.,  a  pistol  killing  a  target  at  1,000  meter). 

Note  1:  When  using  a  physical  interface  to  transfer  the  engagement  data  between  DOs  based  on  line  of  sight 
(e.g.,  laser  or  RF),  the  range  of  the  transfer  method  must  be  at  least  as  large  as  the  effective  range  of  weapon 
and  ammunition  combination. 

Note  2:  Some  current  engagement  systems  use  a  separate  ammunition  code  (called  “ammunition  ID”)  to 
identify  an  ammunition  which  in  fact  is  a  combination  of  a  general  ammunition  type,  a  fuse  type,  fuse  setting 
and  the  distance  (category)  over  which  it  is  deployed.  However,  this  is  a  typical  implementation  issue  and 
such  a  parameter  can  be  derived  from  other  existing  data  elements. 


Detonation  Location 

For  proximity  engagements,  where  the  ammunition  does  not  impact  directly  on  a  target,  this  is  the  three- 
dimensional  location  where  the  ammunition  detonates.  It  is  used  to  determine  which  DOs  are  affected. 


Effect  Direction/Angle  (Vector)  at  the  Moment  of  Detonation 

The  direction  in  which  the  effect  of  the  ammunition  is  projected.  This  can  be  either  omnidirectional 
(e.g.,  a  hand  grenade)  or  a  particular  angle  or  sector  (e.g.,  a  horizontal  effect  weapon).  It  is  used  to  determine 
the  direction  of  the  influence  sphere  of  the  resulting  explosion  and  thereby  which  DOs  are  affected  by  it. 
It  can  also  be  useful  for  monitoring  purposes  (e.g.,  evaluation  of  an  ambush  when  using  horizontal  effect 
weapons). 

Projectile  Impact  Velocity  (Vector) 

The  three-dimensional  speed  of  the  projectile  at  the  moment  of  impact.  From  this,  the  direction  or  three- 
dimensional  angle  of  the  projectile  relative  to  the  target  can  be  inferred.  It  is  used  for  damage  calculation,  for 
the  speed  and  angle  of  impact  are  important  factors  to  determine  if  the  projectile  penetrates  the  armour  of  a 
target,  both  for  kinetic  and  high  explosive  ammunitions. 


Effect  Volume 

The  three-dimensional  volume  of  effect  of  the  exploding  ammunition  in  which  objects  can  be  affected  and 
used  for  damage  calculation.  However  it  can  also  be  used  for  monitoring  purposes  to  visualise  the  effect 
volume  of  the  ammunition. 


Terrain 

The  terrain  is  an  important  factor  for  targeting  (for  example  is  there  line  of  sight  between  two  DOs), 
projection  of  the  trajectory  of  the  projectile  (e.g.,  are  there  any  objects  in  between  the  shooter  and  target)  and 
damage  calculations  (e.g.,  shielding  a  target  from  the  detonation  effects  or  reflection  of  blast). 
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Atmospheric  Data 

Atmospheric  data  contains  information  about  for  example  wind  direction  and  wind  force,  air  pressure, 
temperature  and  humidity.  It  can  influence  the  trajectory  of  projectiles.  Advanced  weapon  systems  take 
atmospheric  conditions  into  account  in  their  fire  control  computer. 

Affected  DO (s)  ID 

The  unique  identification  of  the  Dynamic  Object  or  Dynamic  Objects  that  are  affected  by  the  engagement.  In 
case  of  a  shot  from  a  rifle,  it  could  be  the  single  hit  target.  In  case  of  an  explosion  of  a  bomb,  it  could  be  all 
the  DOs  that  are  present  in  the  effect  volume.  It  is  used  for  damage  calculation  and  monitoring  purposes. 


Affected  DO(s)  Location 

The  three-dimensional  location(s)  of  the  affected  DO(s)  at  the  start  of  the  engagement,  used  for  targeting  and 
monitoring  purposes. 

Affected  DO(s)  Velocity 

The  three-dimensional  speed  of  the  affected  DO(s),  used  for  targeting  and  monitoring  purposes. 


Time  of  Start  of  the  Engagement  (Trigger  Time) 

The  instance  in  time  when  the  engagement  starts,  for  example  the  time  when  a  bullet  is  fired.  When  used  for 
targeting  purposes,  a  high  level  of  accuracy  is  required  (microseconds).  When  used  for  monitoring  purposes, 
a  lower  level  of  accuracy  is  required  (seconds). 

Time  of  End  of  the  Engagement  (Impact  Time) 

The  instance  in  time  when  the  engagement  ends,  for  example  when  a  bullet  hits  a  target  or  when  an 
explosive  round  detonates.  Used  for  targeting  and  monitoring  purposes. 


Point  of  Impact 

The  location  on  the  target  DO  where  the  engagement  affects  the  target.  Typically  it  is  the  location  where  a 
bullet  or  other  projectile  impacts.  It  is  used  for  damage  calculation.  When  concerning  human  targets,  it  must 
be  possible  to  at  least  make  a  distinction  between  the  different  body  parts,  therefore  an  accuracy  of 
sub-decimeter  magnitude  is  required. 

Note:  Some  types  of  ammunition  do  not  have  their  primary  effect  at  the  point  of  impact,  but  elsewhere. 
For  example  the  Bunkerfaust  dual  purpose  ammunition  first  penetrates  a  surface,  before  it  explodes. 
The  location  of  detonation  can  only  be  determined  in  combination  with  the  properties  of  the  affected  target. 
When  highly  armoured,  the  ammunition  will  not  penetrate  the  object  or,  conversely,  when  not  armoured  at 
all,  the  ammunition  could  fly  through  the  object.  It  is  assumed  that  the  vulnerability  model  takes  care  of  this 
calculation. 


Examples 

As  stated,  not  all  parameters  are  required  for  each  engagement.  Table  E-2  shows  three  examples  and  the 
relevant  data  to  characterise  the  engagement:  a  bullet  hitting  a  target,  a  thrown  hand  grenade  and  a  placed 
IED.  There  is  no  requirement  to  consider  a  hand  grenade  as  a  DO,  whose  location  and  status  needs  to  be 
tracked  during  the  exercise.  It  is  sufficient  to  consider  it  as  an  ammunition  (therefore,  no  “Ammunition  ID” 
is  required).  However,  for  training  purposes  (especially  training  up  to  platoon  level)  it  is  relevant  to  record 
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who  has  thrown  the  grenade,  hence  the  “Shooter  ID”.  Although  technically  not  straightforward,  a  pairing  is 
required  between  the  shooter  and  the  hand  grenade. 


Table  E-2:  Engagement  Dataset  fora  Bullet,  Hand  Grenade  and  IED. 


Bullet 

Hand  Grenade 

IED 

Shooter  ID 

Shooter  ID 

(Shooter  ID) 

Shooter  location 

Shooter  location 

(Shooter  location) 

Shooter  velocity 

Shooter  velocity 

(Shooter  velocity) 

Weapon  type 

Weapon  ID 

Weapon  direction/angle 

Ammunition  type 

Ammunition  type 

Ammunition  type 

Ammunition  ID 

Engagement  range 

Engagement  range 

(Engagement  range) 

Detonation  location 

Detonation  location 

Effect  direction/angle 

Effect  direction/angle 

Projectile  impact  velocity 

Effect  volume 

Effect  volume 

Terrain 

Terrain 

Terrain 

Atmospheric  data 

Affected  DO  ID 

Affected  DO(s)  ID 

Affected  DO(s)  ID 

Affected  DO  location 

Affected  DO(s)  location 

Affected  DO(s)  location 

Affected  DO  velocity 

Trigger  time 

Trigger  time 

Trigger  time 

Impact  time 

Impact  time 

Impact  time 

Point  of  impact 

The  IED  is  an  interesting  case  in  itself,  because  depending  on  the  type  of  IED,  certain  parameters  are 
required  or  not: 

•  In  case  of  a  Command  IED  (e.g.,  wire  or  radio  controlled),  the  “Shooter  ID”  is  the  identification  of 
the  DO  who  set  off  the  explosive.  In  general  he  will  be  at  a  certain  distance  from  the  IED,  so  also 
“Engagement  range”  is  of  significance. 

•  In  case  of  a  Victim  Operated  IED,  also  the  “Shooter  ID”  is  of  interest,  while  at  the  same  time  the 
shooter  will  probably  be  also  (one  of)  the  “Affected  DO(s)”.  “Engagement  range”  does  not  seem  to 
be  a  relevant  parameter  for  this  type  of  IED,  since  the  explosive  and  the  trigger  device  are  generally 
close  together  in  order  to  affect  the  victim. 
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From  these  perspectives  a  suicide  IED  can  be  modelled  either  as  a  mobile  Victim  Operated  1ED 
(when  he  sets  the  explosives  off  himself)  or  as  a  mobile  Command  IED  (when  somebody  else 
remotely  operates  the  explosives). 

•  In  case  of  a  Timed  IED  there  is  no  shooter,  but  the  explosive  sets  itself  off  at  a  specific  instance  in 
time.  The  player  deploying  the  IED  (the  emplacer)  is  not  part  of  the  engagement  and  therefore  not 
considered  as  the  shooter. 


E.3  MISSILE  ENGAGEMENTS 

The  missile  engagement  is  closely  related  to  the  contact  and  proximity  dataset.  In  this  case  we  will  only  look 
at  the  missile  itself  and  not  at  the  launcher,  since  the  launcher  is  not  part  of  the  engagement.  The  capabilities 
launchers  have  are  essentially  similar  in  all  available  platforms,  be  it  fixed-wing  or  rotary-wing  aircraft, 
dismounted  or  vehicle  mounted  AT  weapon  systems,  surface-to-surface,  surface-to-air,  air-to-air  or  air-to- 
surface.  Launcher  parameters  are  captured  in  the  existing  superset  with  the  “Weapon  Mode”  line  or  can 
otherwise  be  differentiated  with  weapon  or  ammunition  codes.  The  difficulty  with  the  missile  engagements 
is  in  the  “delivery”  part  of  the  engagement,  the  part  between  launch  and  detonation  or  impact. 

E.3.1  Types  of  Missiles 

The  difference  between  missiles  is  mostly  determined  by  the  kind  of  guidance  system  (if  any)  they  use. 
There  are  a  number  of  categories  in  which  they  can  be  divided: 

1)  Unguided  missiles  (rockets). 

2)  Unguided  missiles  (rockets)  with  advanced  sighting  system. 

3)  Command  guided  missiles: 

a)  MCLOS  (Manual  Command  to  Line-Of-Sight). 

b)  SACLOS  (Semi-Automatic  Command  to  Line-Of-Sight). 

c)  Fire,  observe  and  update  (NLOS). 

4)  Fire-and-forget  missiles. 

E.3. 1.1  Unguided  Missiles  (Rockets) 

According  to  military  definitions  an  unguided,  powered  projectile  is  called  a  rocket.  Because  of  its 
propulsion  method,  size  and  common  launcher  characteristics  we  will  still  consider  it  to  be  a  type  of  missile. 
They  can  either  be  shoulder-,  vehicle-  or  aircraft-launched. 

Examples:  M-136,  RPG-7,  Carl-Gustav,  Katyusha,  Hydra  70. 

E.3. 1.2  Unguided  Missiles,  with  Advanced  Sighting  System 

Basically  this  is  still  the  same  type  of  weapon  as  the  first  category,  in  relation  to  targeting  and  guidance. 
The  only  difference  with  the  first  category  are  the  advanced  sights,  which  can  give  the  weapon  a  lead  angle 
capability  and/or  night-vision  capabilities.  In  most  cases  the  use  of  advanced  sights  extends  the  rockets 
effective  range.  Nevertheless,  all  these  are  capabilities  of  the  sighting  device  and  not  the  missile  itself.  Even 
though  we  already  declared  not  to  look  at  launcher  capabilities,  this  type  of  weapon  system  is  widely  used 
and  needs  to  be  mentioned. 

Examples:  Panzerfaust  3  with  Dynarange  optics. 
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E.3.1.3  Command  Guided  Missiles 

a)  MCLOS  (Manually  command  to  line-of-sight) 

This  guidance  method  entails  that  both  the  missile  and  the  target  have  to  be  tracked  by  the  shooter,  who 
steers  the  missile  towards  the  target.  The  missile  is  typically  steered  by  a  joystick  and  communication  to 
the  missile  is  done  by  wire  or  radio  link.  Because  of  their  low  accuracy,  difficult  method  of  targeting 
(a  lot  of  practice  is  needed)  and  the  presence  of  newer  techniques,  these  kinds  of  weapons  are  pretty 
much  obsolete  in  modem  day  warfare. 

Examples:  AT-3  Sagger,  Blowpipe,  Saab  Rb  05A,  Azon. 

b)  SACLOS  (Semi-automatic  command  to  line-of-sight) 

A  command  guided  missile  remains  in  contact  with  the  launcher  and  needs  to  be  steered  manually 
towards  the  target  by  keeping  the  sights  on  target,  until  impact  occurs.  This  gives  the  shooter  the 
possibility  to  steer  the  projectile  during  flight  toward  a  (for  instance)  moving  target  or  switch  to  a 
different  target.  Communication  between  the  launcher  and  the  missile  is  either  through  wire  and  1R  or 
radio.  The  difference  with  MCLOS  is  that  the  shooter  only  has  to  track  the  target,  not  the  missile. 
Downside  to  both  this  method  and  the  aforementioned  MCLOS,  is  that  even  the  slightest  disturbance 
(explosions,  enemy  fire)  or  loss  of  concentration  can  cause  a  miss  while  the  shooter  has  to  remain  on 
target  (thus  being  visible  to  enemy  troops,  including  the  target)  until  impact. 

A  variation  to  this  method  of  tracking  is  called  line  of  sight  beam  riding  (LOSBR),  where  the  launcher 
projects  a  beam  directly  to  the  target,  which  is  seen  and  followed  by  the  missile.  This  tracking  method  is 
still  considered  to  be  in  the  SACLOS  category,  because  of  the  targeting  method  from  the  launcher  point 
of  view.  The  sights  (or  Laser  Target  Designator  for  that  matter)  also  have  to  stay  on  target  until  impact. 

Examples:  AT-4  Spigot,  MILAN,  M-47  Dragon,  SA-8  Gecko,  Starstreak. 

c)  Fire,  observe  and  update  (NLOS) 

The  latest  generation  of  command  guided  missiles  are  closely  related  to  fire-and-forget  missiles  and  in 
some  cases  have  the  ability  to  switch  between  the  two  modes.  The  main  difference  with  fire-and-forget 
missiles  is  that  this  type  can  switch  targets  in-flight  and  has  the  possibility  of  firing  at  targets  that  are  not 
(yet)  in  line  of  sight  (NLOS).  They  resemble  the  earlier  SACLOS  missiles,  with  the  difference  that  fire, 
observe  and  update  missiles  can  be  “locked”  instead  of  steered  and  in  most  cases  have  an  extended 
range  beyond  line  of  sight.  The  “observe”  function  allows  the  shooter  to  view  real-time  1R  imaging 
from  the  missile.  He  can  therefore  fire  the  missile  “blind”,  with  no  target  locked,  but  can  lock  onto 
targets  acquired  in-flight. 

Examples:  Spike  Extended  Range. 

E.3.1.4  Eire-and-Eorget  Missiles 

These  missiles  require  no  further  guidance  after  launch.  All  necessary  data  is  programmed  into  the  missile 
prior  to  launch  by  either  a  (thermal)  image  of  the  target,  coordinates  or  radar  information.  After  launch  the 
sensors  in  the  missile,  combined  with  the  input  targeting  information  from  the  launcher,  let  it  find  its  own 
way  to  the  target  without  shooter  interference.  This  category  also  covers  anti-radiation  and  homing  missiles 
that  home  in  on  heat  (1R),  negative  UV  or  radio/radar  installations  automatically,  with  minimal  crew  input. 

Examples:  Spike  Gill,  Javelin,  F1M-92  Stinger,  AIM-9  Sidewinder. 

E.3.2  Considerations 

If  we  look  at  all  different  missile  platforms  as  stated  above,  there  are  multiple  ways  to  compare  them. 
Simplified,  they  differ  in  the  ability  to  influence  them  after  launch  and  method  of  guidance. 
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E.3.2.1  Unguided  Missiles  (Rockets) 

First  we  look  at  the  first  two  categories  of  missiles  as  an  example:  the  unguided  missile  or  rocket  (with  or 
without  advanced  sighting).  The  outcome  of  the  engagement  is  practically  decided  at  trigger  time. 
The  shooter’s  aim  is  either  good  or  bad,  but  after  the  trigger  is  pulled  or  the  button  pushed  there  is  no 
influencing  it  anymore.  In  fact,  an  unguided  missile  is  nothing  more  than  a  simple  bullet  in  some  way. 
The  differences  are  its  means  of  propulsion,  the  longer  flight  duration  and  the  higher  payload.  If  we  consider 
these  missiles  to  be  a  simple  bullet  (with  or  without  proximity  effects)  they  are  covered  in  the  earlier 
described  datasets,  with  the  exception  of  an  extra  parameter  for  the  flight  duration. 

E.3.2.2  Fire-and-Forget  Missiles 

Be  it  more  advanced,  the  fire-and-forget  missiles  are  basically  the  same.  At  trigger  time  the  outcome  of  the 
engagement  (from  the  shooter’s  point  of  view)  is  basically  decided,  and  again,  no  influence  is  possible 
in-flight. 

Of  course  there  are  also  factors  of  influence  on  the  target  side,  but  that  calculation  is  done  elsewhere. 
All  information  (the  dataset)  that  is  known  at  trigger  time  (from  the  shooter)  can  be  sent  at  once,  as  it  will  not 
change  during  flight.  Even  though  no  further  information  is  needed  for  guidance  the  flight  duration  of  the 
missile  has  to  be  taken  into  account  before  any  effect  on  the  target  can  be  declared. 

E.3.2.3  Command  Guided  Missiles 

If  all  other  missiles  are  considered  “advanced  bullets  with  different  propulsion  and  payload”  and  are  covered 
by  existing  datasets,  with  and  extra  parameter  for  flight  duration.  This  leaves  us  with  only  one  category  to 
cover;  the  ones  that  can  be  influenced  by  the  launcher  during  flight.  This  category  is  more  difficult  as  more 
factors  are  influencing  the  outcome  of  the  engagement,  over  a  longer  period  of  time. 

In  an  earlier  stage  it  was  decided  that  an  engagement  starts  at  the  moment  the  trigger  is  pulled  (or  the  button 
pushed)  and  that  it  ends  at  the  moment  of  impact  (or  miss).  For  a  command  guided  missile  that  means  a 
couple  of  things  happen  at  trigger  time. 

The  first  one  is  that  a  countdown  timer  starts  ticking,  which  is  basically  a  rendition  of  the  missile’s  flight 
duration.  Duration  of  flight  is  determined  by  multiple  factors:  distance  to  target,  trajectory  (weapon  mode), 
ballistics,  atmospheric  data,  vector  of  the  launcher  and  vector  of  the  target.  All  of  this  data  is  already  in  the 
existing  dataset.  The  flight  duration  basically  determines  the  window  of  time  in  which  targeting  corrections 
can  be  made. 

The  second  deciding  factor  is  where  the  sights  are  aimed  at  the  moment  the  clocks  stops  ticking  and 
“Time  of  impact  (or  detonation)”  is  reached.  After  that,  damage  calculation  is  done  (or  not,  in  case  of  a 
miss).  The  fact  that  there  is  a  certain  “slowness”  in  steering  corrections  (missile  response  time)  should  be 
implemented  in  the  training  system  (e.g.,  corrections  made  just  before  impact  have  no  effect  anymore  on  the 
point  of  impact). 

A  third  (auxiliary)  factor  that  has  to  be  taken  in  to  account  is  the  fact  that  the  way  targeting  corrections  are 
made  by  the  launcher  have  to  be  given  limitations.  In  reality,  if  the  launcher  makes  a  lot  of  sudden 
movements  or  moves  with  a  high  radial  speed,  he  will  “lose”  the  missile.  Functionality  has  to  be 
implemented  in  the  training  system  to  detect  if  the  launcher  exceeds  its  limitations  and  abort  the  engagement 
in-flight  or  determine  whether  a  hit  or  miss  occurs.  Determining  if  the  shooter  stayed  within  given  guidance 
limitations  can  be  decided  during  or  after  the  flight  time  has  ended.  To  declare  that  to  the  target  an  additional 
parameter  is  introduced:  “Engagement  validation”.  Engagement  validation  is  a  flag  whose  value  is 
determined  by  shooter  performance  during  missile  guidance  and  decides  whether  a  hit  or  miss  takes  place. 
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An  additional  factor  that  can  be  into  play  is  the  presence  of  a  target  designator.  The  designator  can  assist  the 
shooter  in  guiding  the  missile  or  take  over  guidance  altogether.  Since  the  shooter  and  the  designator  are  not 
necessarily  the  same,  but  are  part  of  the  same  engagement,  additional  parameters  are  needed.  Assuming  the 
designator  can  have  the  same  role  as  the  shooter,  the  same  parameters  are  needed.  These  include  designator 
ID,  designator  position  (x,  y,  z)  and  vector  (speed  and  direction).  The  designator  ID  is  not  only  for 
monitoring  purposes  but  for  targeting  purposes  as  well.  When  a  designator  assists  a  shooter,  chances  of  a  hit 
are  normally  greatly  improved.  Therefore,  the  presence  of  a  designator  has  to  be  taken  into  account. 

Equal  to  the  shooter,  the  designator  has  to  meet  the  same  conditions  in  order  not  to  lose  guidance  of  a 
missile.  When  a  shooter  or  designator  makes  too  many,  too  sudden  or  too  large  movements,  guidance  shoidd 
be  lost. 

It  is  noted  that  the  fidelity  of  simulating  the  accuracy  of  missile  guidance  should  be  sufficient  to  ensure  fair 
play  between  shooter/designator  and  target.  For  skill  training,  a  higher  level  of  fidelity  might  be  required. 

E.3.3  Conclusions 

Missiles  are  a  category  of  projectiles  that  differ  from  ballistic  ammunition  in  propulsion,  targeting/homing 
capabilities,  flight  duration,  trajectory  and  payload.  Propulsion  is  irrelevant  in  this  case  because  it  is  not 
simulated.  Payload  is  a  parameter  that  is  important  for  damage  calculation  but  in  the  end  nothing  more  than  a 
weapon  code  and  true  pyrotechnic  effects  are  also  not  simulated. 

In  a  simulation  sense  it  is  targeting  we  are  mostly  interested  in  as  it  is  more  difficult  to  simulate  and  highly 
important  for  the  level  of  fidelity  of  the  simulation. 

There  are  several  new  parameters  to  be  added  to  the  dataset  we  determined  for  contact  and  proximity 
engagements.  These  are  highlighted  in  orange  in  the  table  below.  One  of  them  is  Duration  of  flight. 
The  accuracy  should  be  in  microseconds,  because  of  the  high  speed  a  missile  can  have  and  therefore  the 
distance  it  can  cover  in  a  single  time-frame. 

As  for  fire-and-forget  missiles,  the  time  until  engagement  has  to  be  declared  to  the  target.  However,  this 
value  is  the  same  as  the  “Duration  of  flight”  so  no  extra  line  needs  to  be  added  to  the  dataset.  To  keep 
engagements  with  fire-and-forget  missiles  fair,  a  certain  hit  probability  has  to  be  taken  into  account  when 
calculating  impact  and  damage. 

Next  to  a  shooter,  a  designator  can  be  part  of  the  same  engagement  (one  missile,  one  target).  He  can  assist 
the  shooter  for  a  higher  accuracy  of  targeting  or  he  can  take  over  the  missile  guidance  entirely.  In  the  case  of 
assistance,  providing  a  designator  ID  might  be  enough  as  a  flag  that  gives  higher  accuracy.  But  since 
guidance  can  be  completely  taken  over  by  the  designator,  the  same  parameters  have  to  be  known  for  the 
designator  as  well.  These  parameters,  next  to  the  designator  ID,  are  its  location  and  speed  and  direction 
(vector). 

During  flight  the  shooter  or  designator  can  move  his  sights  around  within  limits  of  maximum  radial  speed  or 
g-forces  and  within  the  duration  of  flight.  The  parameter  “Engagement  validation”  signals  whether  the 
shooter  or  designator  stays  within  these  limits,  and  the  point  of  impact  is  determined  when  the  flight  duration 
is  reached. 

E.3.4  Missile  Engagement  Superset 

Designator  properties,  flight  time  and  engagement  validation  are  added  to  the  direct  engagement  dataset  and 
marked  in  orange. 
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Table  E-3:  Engagement  Dataset  for  Missiles. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Shooter  ID 

MONITORING 

ID 

15,000 

- 

Shooter  location  (x,  y,  z), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub-decimeter 

Shooter  velocity  (vector), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

Designator  ID 

TARGETING 

MONITORING 

ID 

15,000 

- 

Designator  location  (x,  y,  z), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub-decimeter 

Designator  velocity  (vector), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

Weapon  type 

MONITORING 

Category 

- 

Weapon  ID 

ANALYSIS 

ID 

- 

Shooter  weapon  mode 

TARGETING 

MONITORING 

Category 

- 

Trigger  type  of  the  event 

ANALYSIS 

Category 

- 

Weapon  direction/angle 
(vector),  plus  accuracy 
indicator 

TARGETING 

VERY  HIGH 

Ammunition  type 

DAMAGE 

CALCULATION 

Category 

- 

Ammunition  ID 

MONITORING 

ID 

- 

Duration  of  flight 

TARGETING 

Seconds 

Micro-second 

Engagement  range 

DAMAGE 

CALCULATION 

MONITORING 

Meter 

Meter 

Engagement  validation 

TARGETING 

YES/NO 

- 

Detonation  location  (x,  y,  z), 
plus  accuracy  indicator 

DAMAGE 

CALCULATION 

MONITORING 

Meter 

Sub-decimeter 

Effect  direction/angle  (vector) 
at  the  moment  of  detonation 

DAMAGE 

CALCULATION 

HIGH 

Effect  volume 

DAMAGE 

CALCULATION 

Meter 

Meter 

Terrain 

TARGETING 

DAMAGE 

CALCULATION 

Meter 

Sub-decimeter 

Atmospheric  data 

TARGETING 

- 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Affected  DO(s)  fD 

DAMAGE 

CALCULATION 

ID 

- 

Affected  DO(s)  location  (x,  y, 
z),  plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub-decimeter 

Affected  DO(s)  velocity 
(vector),  plus  accuracy 
indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

Time  of  start  of  the 
engagement  (trigger  time), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Seconds 

Micro-second 

Time  of  end  of  the 
engagement  (impact  time), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Seconds 

Micro-second 

Point  of  impact 

DAMAGE 

CALCULATION 

Meter 

Sub-decimeter 

Projectile  impact  velocity 
(vector),  plus  accuracy 
indicator 

DAMAGE 

CALCULATION 

Meter/sec 

As  required 

E.3.4.1  Designator 

It  is  possible  that  the  weapon  system  or  person  who  fires  the  missile,  is  not  the  same  as  who  aims/guides  the 
missile  (the  designator).  Therefore  there  is  a  need  to  incorporate  both  the  shooter  properties  and  the 
designator  properties  (ID,  location,  velocity). 

E.3.4.2  Duration  of  Flight 

The  duration  it  takes  for  the  missile  to  fly  from  the  moment  of  launch  till  the  point  of  impact/detonation. 

E.3.4.3  Engagement  Validation 

During  the  flight  of  the  missile,  the  designator  can  adjust  the  flight  path  to  compensate  for  movements  of  the 
target  or  even  to  switch  to  another  target.  However,  when  making  too  many,  too  large  or  too  sudden 
adjustments,  the  designator  can  lose  the  control  over  the  missile.  Only  when  the  designator  stays  within  the 
limits  of  these  conditions,  the  missile  can  hit  the  target.  It  is  noted  that  the  fidelity  of  simulating  the  accuracy 
of  missile  control  should  be  sufficient  to  ensure  fair  play  between  designator  and  target.  Skills  training  for 
the  missile  designator  could  require  a  higher  fidelity  simulation. 

E.3.5  Final  Thoughts 

The  missile  engagement  dataset  is  one  of  the  more  challenging  datasets  to  be  covered  under  the  UCATT 
standard. 

The  proposed  solution  for  missile  engagement  is  not  perfect.  It  has  some  flaws  and  loopholes.  From  fair  play 
perspective  however,  it  is  probably  sufficient  to  meet  training  needs  at  this  moment.  Future  technology 
advancement  might  provide  higher  levels  of  fidelity  and  have  to  be  addressed  in  future  versions  of  the 
UCATT  standard. 
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E.4  AREA  ENGAGEMENTS 

There  can  be  certain  areas  in  the  environment  that  can  affect  the  status  of  DOs.  An  area  engagement  is 
defined  as  the  situation  where  the  location  of  such  an  area  and  the  location  of  a  DO  coincide.  The  engagement 
ends  when  the  DO  leaves  the  area,  the  area  ceases  to  exist  or  the  DO  is  killed. 

E.4.1  Minefields 

Minefields  are  a  collection  of  mines  located  in  the  same  area.  They  can  be  simulated  as  individual  mines, 
either  physically  placed  in  the  live  environment  or  virtually  simulated  in  the  training  system  (“EXCON”). 
In  both  cases  the  interaction  with  these  mines  is  a  contact  or  proximity  engagement  as  described  in  Section 

D. 2.  Although  the  engagement  is  between  an  individual  mine  and  one  or  more  DOs,  the  minefield  has  a 
tactical  relevance.  For  that  reason  it  is  important  to  know  how  many  DOs  were  affected  by  the  minefield, 
in  other  words,  how  effective  the  minefield  was  (and  not  only  the  individual  mines).  Therefore  it  is  required 
that  the  mines  can  be  grouped  into  a  higher  level  concept  of  minefield,  with  a  specific  minefield  identification. 

However,  there  are  also  training  systems  that  simulate  a  minefield  as  an  area  wherein  a  DO  has  a  certain 
probability  of  getting  struck  by  a  mine,  without  simulating  each  individual  mine.  In  this  case  and  dependent 
upon  the  characteristics  of  the  minefield  (mine  type,  density  etc.),  “a  dice  is  rolled”  for  any  DO  upon 
entering  the  minefield  and  in  better  systems  this  continues  whilst  the  DO  move  within  the  minefield.  This  is 
a  Monte-Carlo  simulation. 

Simulation  of  individual  mines  is  a  more  realistic  implementation.  For  backward  compatibility  reasons  the 
implementation  of  minefields  as  probability  areas  is  taken  into  account. 

In  UCATT  terms  a  probability  area  is  not  considered  as  a  DO  itself,  but  part  of  EXCON,  and  therefore  the 
interaction  with  DOs  is  part  of  E3,  “Control  Dynamic  Object  Status”.  But  given  the  close  relation  with 
interactions  between  DOs  they  are  defined  in  this  annex. 

E. 4. 1.1  Minefield  Creation  and  Deactivation 


Table  E-4:  Minefield  Creation  Dataset  (When  Modelled  as  Probability  Areas). 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Minefield  ID 

MONITORING 

ID 

- 

Emplacer  ID 

MONITORING 

ID 

15,000 

- 

Minefield  location 

TARGETING 

Meter 

1,000 

Sub-decimeter 

Ammunition  type(s) 

DAMAGE 

CALCULATION 

Category 

- 

Ammunition  type  density 

TARGETING 

Mines/m2 

0.01 

Activation  time 

TARGETING 

Seconds 

Second 

Minefield  ID 

Unique  identifier  identifying  a  minefield. 
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Emplacer  ID 

The  identification  of  the  DO  that  created  the  minefield.  Minefields  can  be  created  by  a  minescattering 
vehicle,  delivered  by  artillery  (FASCAM),  by  air  or  can  be  hand  emplaced.  In  training  systems  they  can  also 
be  laid  by  EXCON.  When  applicable,  for  monitoring  purposes,  the  ID  of  the  emplacer  can  be  recorded. 


Minefield  Location 

The  location  of  the  minefield,  defined  as  a  polygon  (square,  rectangle  or  other  more  complex  pattern). 
The  comers  of  the  polygon  are  to  be  specified  with  an  accuracy  of  a  sub-decimeter.  This  high  accuracy  is 
required  because  in  an  urban  environment  the  locations  of  DOs  are  also  very  accurate.  It  is  also  noted  that 
minefields  in  an  urban  environment  are  smaller  than  tactical  minefields  in  open  country  to  deny  access  to 
large  fields  and  block  access  ways. 


Ammunition  Type(S) 

The  type(s)  of  mine  of  which  the  minefield  is  made  up.  A  minefield  can  contain  multiple  types  of  mines 
(e.g.,  a  combination  of  anti-personnel  and  anti-tank  mines). 


Ammunition  Type  Density 

The  number  of  mines  per  square  meter,  specified  for  each  type  of  mine  in  the  minefield.  Typically,  mines  are 
laid  in  rows  and  a  density  of  an  order  of  magnitude  of  0.4  mines/m2  is  considered  sufficient  to  create  an 
effective  minefield.  But  it  must  also  be  possible  to  create  large  minefields  with  a  smaller  density,  hence  the 
accuracy  of  0.01  mines/m2. 


Activation  Time 

The  instance  in  time  when  the  minefield  is  laid  or  activated. 


Deactivation  Time 

The  instance  in  time  when  the  minefield  is  cleared  or  deactivated. 


Table  E-5:  Minefield  Deactivation  Dataset  (When  Modelled  as  Probability  Areas). 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Minefield  ID 

MONITORING 

ID 

- 

Deactivation  time 

TARGETING 

Seconds 

Second 

E.4.1.2  Minefield  Engagements 


Table  E-6:  Minefield  Engagement  Dataset  (When  Modelled  as  Probability  Areas). 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Minefield  ID 

MONITORING 

ID 

- 

Engagement  time 

MONITORING 

Seconds 

Second 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Terrain 

TARGETING 

DAMAGE 

CALCULATION 

Affected  DO(s)  ID 

DAMAGE 

CALCULATION 

ID 

- 

Affected  DO(s)  location 

DAMAGE 

CALCULATION 

Meter 

- 

Engagement  Time 

The  instance  in  time  when  the  DO  is  engaged  (the  dice  is  rolled).  A  DO  can  be  engaged  multiple  times  by 
the  same  minefield  (as  long  as  he  keeps  moving  in  the  minefield). 


Terrain 

The  soil  can  influence  the  triggering  of  buried  mines  and  can  also  influence  the  damage  to  DOs. 

Affected  DO (s)  ID 

The  identification  of  the  DO(s)  that  are  affected  by  the  engagement.  Although  one  DO  can  trigger  a  mine, 
multiple  DOs  in  its  direct  vicinity  might  be  affected. 


Affected  DO(s)  Position 

The  three-dimensional  location(s)  of  the  affected  DO(s). 

E.4.1.3  Clearing  of  Mines  and  Minefields 

E.  4. 1.3.1  Clearing  a  Single  Mine  or  IED 

For  the  case  where  a  single  device  (mine  of  IED)  is  deployed  there  are  several  possibilities  to  clear  it: 

•  Shooting  at  it.  This  means  the  mine  has  to  be  visible  in  the  training  environment  and  the  mine  needs 
to  be  modelled  as  a  DO,  able  to  sense  it  is  shot  at.  Under  these  conditions  this  is  a  contact 
engagement. 

•  Placing  and  initiating  an  explosive  charge  next  to  it.  If  the  mine  and  explosive  charge  both  are 
modelled  as  a  DO,  this  is  a  proximity  engagement. 

•  If  there  is  a  requirement  that  the  mine  can  be  influenced  by  fire  support  (artillery  or  aerial  bombs), 
this  can  be  modelled  as  an  artillery  area  engagement. 

•  EOD  clearance.  Depending  on  the  type  of  mine  or  IED,  the  EOD  operators  will  take  the  appropriate 
measures  regarding  the  device.  It  is  important  that  the  deployment  of  an  EOD  team  and  the  required 
conditions  and  associated  timings  can  be  simulated.  Therefore  it  will  suffice  that  the  training  system 
allows  the  operator  to  initiate  the  type  of  activity  and  subsequently  after  a  specified  time  the  status  of 
the  mine  or  IED  will  be  changed.  The  exact  operations  on  the  device  with  realistic  sensitivity  do  not 
need  to  be  simulated. 

The  engagement  therefore  requires  the  datasets  presented  in  Table  E-7. 
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Table  E-7:  Mine  Clearing  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Operator  ID 

TARGETING 

ID 

- 

Mine  ID 

TARGETING 

ID 

- 

Activity 

DAMAGE 

CALCULATION 

Category 

- 

Time  of  start  of  the 
engagement 

TARGETING 

MONITORING 

Seconds 

Second 

Time  of  end  of  the 
engagement 

TARGETING 

MONITORING 

Seconds 

Second 

Operator  ID 

The  DO  that  attempts  to  clear  the  mine  of  1ED.  If  required,  this  ID  can  be  used  to  determine  if  the  operator  is 
qualified  to  clear  the  mine,  influencing  the  result  of  the  activity. 

Mine  ID 

The  identification  of  the  mine  or  1ED  that  is  to  be  cleared. 


Activity 

The  activity  that  the  operator  has  chosen  to  clear  the  mine  or  1ED. 

Time  of  Start  of  the  Engagement 

The  instance  in  time  the  clearing  activity  is  started. 

Time  of  End  of  the  Engagement 

The  instance  in  time  the  clearing  activity  is  interrupted  or  ended,  resulting  in  a  changed  state  or  not. 

E.  4. 1.3. 2  Clearing  a  Minefield 

For  the  case  where  a  conventional  minefield  is  deployed  and  which  is  created  using  the  probability  area 

method  there  are  several  possibilities  to  clear  it  or  a  path  through  it. 

•  Mine  clearing  vehicle.  When  the  vehicle  satisfies  certain  conditions  (such  as  “in  mine  clearing 
mode”  and  “does  not  drive  faster  than  mine  clearing  speed”),  contact  mines  in  the  minefield  will 
have  no  major  effect  on  the  vehicle  and  it  will  create  in  its  wake  a  safe  passage  lane.  Elowever, 
a  mine  clearing  vehicle  typically  can  only  sustain  a  certain  number  of  blasts,  depending  on  the  type 
of  mine.  This  functionality  is  part  of  the  damage  model  of  the  vehicle. 

•  Dismounted  mine  clearing  team.  It  is  important  that  the  deployment  of  a  mine  clearing  team  and  the 
required  conditions  and  associated  timings  can  be  simulated.  It  will  suffice  that  the  training  system 
allows  the  dismounted  team  to  traverse  the  minefield  and  when  certain  conditions  are  satisfied, 
a  passage  lane  will  be  created  in  their  wake. 

•  Explosive  charges.  Systems  exist  that  can  fire  a  rope  of  explosives  which  will  detonate  mines  in  the 
vicinity,  thereby  creating  a  passage  lane.  It  is  important  that  such  a  vehicle  can  manoeuvre  on  the 
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battlefield  and  initiate.  Exact  simulation  of  the  explosive  rope  is  not  required,  it  suffices  that  they 
can  notify  EXCON  who  will  create  a  passage  lane. 

•  In  reality  it  is  possible  that  firing  artillery  on  a  minefield  can  displace  or  even  destroy  some  mines. 
This  can  be  modelled  as  a  change  of  the  hit  probability  of  the  minefield.  However,  since  artillery 
cannot  completely  clear  a  minefield  or  even  a  safe  passage  lane,  it  is  not  required  that  artillery  can 
influence  minefields. 

When  the  minefield  is  composed  of  individually  modelled  mines,  the  example  situations  are  described  in  the 
previous  paragraph. 

E.  4. 1.3. 3  Use  of  Minesweepers 

•  When  used  in  combination  with  physically  placed  (simulated)  mines,  the  real  equipment  can  be  used. 

•  Nowadays  systems  exist  to  instrument  minesweeping  equipment.  It  can  be  used  to  collect  data  on  the  use 
of  minesweepers  for  monitoring  purposes,  so  it  can  be  determined  if  the  users  operate  the  equipment 
according  to  standard. 

•  Physical  minesweeping  equipment  could  be  used  in  combination  with  virtual  mines  and  minefields  but 
since  visual  cues  for  the  operators  are  an  important  part  of  the  mine  sweeping  process  and  would  not  be 
easily  available,  this  functionality  is  not  required. 

E.4.2  Fire  Support  Target  Areas 

A  fire  support  target  area  is  the  3-dimensional  space  where  the  ammunitions  of  a  fire  support  mission  land  or 
detonate.  This  can  be  mortar  or  artillery  fire  or  aerial  bombardments.  When  fire  support  is  modelled  as 
(a  series  of)  individual  munitions,  the  interaction  with  the  ammunitions  are  proximity  engagements  as 
described  in  Section  D.2. 

Fire  support  can  also  be  simulated  as  an  area  wherein  a  DO  has  a  certain  probability  of  getting  engaged  by  a 
delivered  projectile,  without  simulating  each  individual  projectile.  Based  on  the  characteristics  of  a  fire 
support  mission,  a  dice  is  rolled  when  and  as  long  as  the  DO  is  within  the  influence  of  the  active  fire  support 
target  area.  The  implementation  of  fire  support  target  areas  as  probability  areas  is  taken  into  account. 


Table  E-8:  Fire  Support  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Fire  support  target  area  ID 

MONITORING 

ID 

- 

Shooter  ID 

MONITORING 

ID 

15,000 

- 

Fire  support  target  area  location 

TARGETING 

Meter 

Meter 

Fire  support  target  area  shape 

TARGETING 

Meter 

1,000 

Meter 

Ammunition  type 

DAMAGE 

CALCULATION 

Category 

- 

Fuse  type 

TARGETING 

Category 

Fuse  settings 

TARGETING 

Number  of  received  salvo’s 

TARGETING 

Integer 

1 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Ammunition  rounds  per  received 
salvo 

TARGETING 

Rounds/ 

salvo 

1 

Activation  time 

TARGETING 

Seconds 

Second 

Deactivation  time 

TARGETING 

Seconds 

Second 

Engagement  time 

MONITORING 

Seconds 

Second 

Terrain 

TARGETING 

DAMAGE 

CALCULATION 

Affected  DO(s)  ID 

DAMAGE 

CALCULATION 

ID 

- 

Affected  DO(s)  location 

DAMAGE 

CALCULATION 

Meter 

- 

Angle  of  impact 

DAMAGE 

CALCULATION 

- 

Fire  Support  Target  Area  ID 

Unique  identifier  identifying  a  fire  support  target  area. 


Shooter  ID 

The  identification  of  the  DO  that  executes  the  fire  support  mission.  However,  it  can  also  be  a  unit 
identification,  since  a  fire  mission  is  executed  by  one  or  more  mortars,  artillery  guns,  rocket  launchers  or 
airborne  platforms.  When  applicable,  it  is  used  for  monitoring  purposes. 


Fire  Support  Target  Area  Location 

The  location  of  the  fire  support  area,  expressed  in  world  coordinates. 

Fire  Support  Target  Area  Shape 

The  shape  or  volume  of  the  fire  support  target  area,  defined  as  a  polygon  (square,  rectangle  or  other  more 
complex  pattern).  The  boundaries  of  the  polygon  are  to  be  specified  with  an  accuracy  of  1  meter. 


Ammunition  Type 

The  type  of  ammunition  used  in  the  fire  mission. 


Fuse  Type 

The  type  of  fuse  used  for  an  ammunition.  This  determines  whether  the  detonation  of  the  ammunition  is 
triggered  by  for  example  physical  contact,  time,  a  sensor  (e.g.,  heat  signature,  radar  signature,  laser  pointed) 
or  a  combination  of  triggers.  The  type  of  fuse  determines  the  point  of  detonation  and  thus  is  used  for 
targeting. 
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Fuse  Settings 

Depending  on  the  type  of  fuse,  certain  settings  can  be  applied. 


Number  of  Received  Salvos 

Artillery  is  typically  fired  in  layers:  a  number  of  guns  fire,  reload  and  fire  again.  This  parameter  is  the 
number  of  salvos  in  the  fire  mission.  This  is  seen  from  the  target  point  of  view:  the  number  of  times  a  series 
of  shells  explode  roughly  simultaneously.  When  artillery  uses  techniques  like  Multiple  Rounds  Simultaneous 
Impact  (MRS1),  a  gun  can  fire  several  times  consecutively,  but  the  rounds  impact  at  the  same  time,  thus 
making  up  one  received  salvo.  At  each  receiving  salvo,  the  DOs  can  be  engaged  again. 


Ammunition  Rounds  per  Received  Salvo 

The  number  of  shells  per  salvo.  It  is  assumed  the  shells  are  evenly  spread  over  the  fire  support  target  area, 
so  from  this  parameter  the  density  can  be  inferred  (and  thus  the  probability  of  being  hit). 


Activation  Time 

The  instance  in  time  when  the  fire  support  target  area  is  activated  (the  first  round  detonates). 


Deactivation  Time 

The  instance  in  time  when  the  fire  support  target  area  is  deactivated  (end  of  the  fire  mission,  the  last  round 
detonates). 


Engagement  Time 

The  instance  in  time  when  the  DO  is  engaged  (the  dice  is  rolled).  A  DO  can  be  engaged  multiple  times  by 
the  same  fire  support  target  area  (as  long  as  he  stays  located  in  the  fire  support  target  area  and  rounds  are 
being  fired,  typically  at  each  salvo). 


Terrain 

The  terrain  can  influence  the  damage  to  DOs,  either  (partly)  shielding  them  from  the  fire  support  effects  or 
even  increasing  the  effects  (e.g.,  firing  in  woods). 

Affected  DO (s)  ID 

The  identification  of  the  DO(s)  that  are  affected  by  the  engagement. 

Affected  DO(s)  Position 

The  three-dimensional  location(s)  of  the  affected  DO(s). 


Angle  of  Impact 

The  angle  at  which  shells  fall  influences  their  lethality.  For  example,  mortar  rounds  come  in  at  a  very  steep 
angle  and  consequently  have  a  more  or  less  proportionally  omnidirectional  effect.  Artillery  shells  can  come 
in  at  a  lower  angle,  where  part  of  the  blast  and  fragmentation  is  dispersed  in  the  ground  and  in  the  air. 
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E.4.3  CBRN  Areas 

CBRN  areas  are  areas  which  contain  a  toxic  agent  and  can  affect  DOs.  CBRN  areas  come  in,  at  least, 
two  forms,  a: 

1)  Contaminated  area,  which  is  static  and  sticks  to  the  ground,  infrastructure  and  other  objects. 

2)  Cloud,  which  is  dynamic  and  due  to  the  influence  of  atmospheric  conditions  (wind,  temperature, 
humidity,  etc.),  changes  its  location,  shape,  size  and  density  (and  therefore  its  effect)  over  time.  It  is 
assumed  that  the  simulation  of  the  dynamic  behaviour  of  a  CBRN  area  is  a  separate  function, 
not  part  of  the  engagement. 

A  CBRN  attack  can  result  in  both  a  static  contaminated  area  and  a  dynamic  cloud.  In  that  case  it  is  assumed 
that  the  attack  resulted  in  two  different  CBRN  areas,  the  static  and  the  dynamic  area. 

E.4.3. 1  CBRN  Area  Creation  and  Deactivation 


Table  E-9:  CBRN  Area  Creation  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

CBRN  area  ID 

MONITORING 

ID 

- 

Shooter  ID 

MONITORING 

ID 

15,000 

- 

CBRN  area  location 

TARGETING 

Meter 

Meter 

CBRN  area  shape 

TARGETING 

Meter 

10,000 

Meter 

Agent  type 

DAMAGE 

CALCULATION 

Category 

- 

Agent  density 

DAMAGE 

CALCULATION 

ppm 

1 

Activation  time 

TARGETING 

Seconds 

Second 

CBRN  Area  ID 

Unique  identifier  identifying  a  CBRN  area. 


Shooter  ID 

The  identification  of  the  DO  that  initiated  the  CBRN  area.  However,  just  like  artillery,  it  can  also  be  a  unit 
identification,  since  a  CBRN  area  can  be  caused  by  one  or  more  actors.  When  applicable,  it  is  used  for 
monitoring  purposes. 


CBRN  Area  Location 

The  location  of  the  CBRN  area,  expressed  in  world  coordinates. 


CBRN  Area  Shape 

The  shape  or  volume  of  the  CBRN  area,  either  defined  as  a  two-dimensional  polygon  (for  static  contaminated 
areas)  or  as  a  three-dimensional  polygon  (for  dynamic  clouds).  The  boundaries  of  the  polygon  are  to  be 
specified  with  an  accuracy  of  1  meter. 
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Agent  Type 

The  type  of  agent  the  CBRN  area  contains. 

Agent  Density 

The  amount  of  agent  per  volume,  expressed  as  parts  per  million. 
Activation  Time 

The  instance  in  time  when  the  CBRN  area  is  activated. 

Deactivation  Time 

The  instance  in  time  when  the  CBRN  area  ceases  to  be  effective. 


Table  E-10:  CBRN  Area  Deactivation  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

CBRN  area  ID 

MONITORING 

ID 

- 

Deactivation  time 

TARGETING 

Seconds 

Second 

E.4.3.2  CBRN  Area  Engagements 


Table  E-11:  CBRN  Area  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

CBRN  area  ID 

MONITORING 

ID 

- 

Engagement  time 

MONITORING 

Seconds 

Second 

Engagement  duration 

DAMAGE 

CALCULATION 

Seconds 

Second 

Affected  DO(s)  ID 

DAMAGE 

CALCULATION 

ID 

- 

Affected  DO(s)  location 

DAMAGE 

CALCULATION 

Meter 

- 

Terrain 

TARGETING 

- 

Atmospheric  data 

TARGETING 

- 

Engagement  Time 

The  instance  in  time  when  the  DO  is  engaged,  upon  entering  the  CBRN  area. 

Engagement  Duration 

The  duration  of  time  the  affected  DO  is  exposed  to  the  CBRN  area.  The  longer  he  stays  within  the  CBRN 
area  and  is  not  properly  protected,  the  more  severe  the  effect  will  be. 
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Affected  DO (s)  ID 

The  identification  of  the  DO(s)  that  are  affected  by  the  engagement. 

Affected  DO(s)  Position 

The  location(s)  of  the  affected  DO(s). 

Terrain 

The  terrain  can  influence  the  properties  of  the  CBRN  area. 

E.4.4  CBRN  Decontamination  Areas 

DOs  can  be  decontaminated  by  special  CBRN  units.  In  reality,  a  CBRN  unit  will  set  up  a  decontamination 
station,  where  they  will  thoroughly  clean  contaminated  vehicles  and  personnel.  For  training  purposes  in  the 
tactical  context  of  live  instrumented  exercises,  it  is  sufficient  to  simulate  a  decontamination  area  and  when 
certain  conditions  are  satisfied  (typically  that  a  DO  must  remain  for  a  certain  period  of  time  within  the 
decontamination  area),  decontamination  is  considered  successful.  At  this  point  here  are  no  requirements  to 
simulate  decontamination  vehicles,  decontamination  liquids,  etc. 

E.4.4. 1  CBRN  Decontamination  Area  Creation  and  Deactivation 


Table  E-12:  Decontamination  Area  Creation  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Decontamination  area  ID 

MONITORING 

ID 

- 

Shooter  ID 

MONITORING 

ID 

15,000 

- 

Decontamination  area 
location 

TARGETING 

Meter 

1000 

Meter 

Activation  time 

TARGETING 

Seconds 

Second 

Decontamination  Area  ID 

Unique  identifier  identifying  a  decontamination  area. 

Shooter  ID 

The  identification  of  the  DO  that  initiated  the  decontamination  area.  Typically  it  will  be  a  unit  identification. 
When  applicable,  it  is  used  for  monitoring  purposes. 

Decontamination  Area  Location 

The  location  of  the  decontamination  area,  either  defined  as  a  two-dimensional  polygon.  The  comers  of  the 
polygon  are  to  be  specified  with  an  accuracy  of  1  meter. 

Activation  Time 

The  instance  in  time  when  the  decontamination  area  is  activated. 
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Deactivation  Time 

The  instance  in  time  when  the  decontamination  area  is  deactivated. 


Table  E-13:  Decontamination  Area  Deactivation  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Decontamination  area  ID 

MONITORING 

ID 

- 

Deactivation  time 

TARGETING 

Seconds 

Second 

E.4.4.2  CBRN  Decontamination  Area  Engagements 


Table  E-14:  Decontamination  Area  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Decontamination  area  ID 

MONITORING 

ID 

- 

Engagement  time 

MONITORING 

Seconds 

Second 

Engagement  duration 

DAMAGE 

CALCULATION 

Seconds 

Second 

Affected  DO(s)  ID 

DAMAGE 

CALCULATION 

ID 

- 

Affected  DO(s)  location 

DAMAGE 

CALCULATION 

Meter 

- 

Engagement  Time 

The  instance  in  time  when  the  DO  is  engaged,  upon  entering  the  CBRN  decontamination  area. 

Engagement  Duration 

The  duration  of  time  the  affected  DO  is  exposed  to  the  CBRN  decontamination  area.  Depending  on  the  type 
of  contamination  of  a  DO,  the  DO  must  remain  a  certain  amount  of  time  within  the  decontamination  area, 
before  the  decontamination  is  successful. 

Affected  DO (s)  ID 

The  identification  of  the  DO(s)  that  are  affected  by  the  engagement. 

Affected  DO(s)  Location 

The  location(s)  of  the  affected  DO(s). 


E.5  ENERGY  WEAPONS 

Energy  weapons  emit  energy  and  thereby  can  influence  Dynamic  Objects.  There  are  two  types  of  energy 
weapons: 

1)  Weapons  that  emit  one  burst  of  energy,  like  for  example  a  (nuclear)  Electro  Magnetic  Pulse  (EMP) 
or  a  flash-bang  grenade,  which  generates  simultaneously  an  intense  flash  of  light  and  a  pressure  and 
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strong  sound  wave.  These  types  of  weapon  can  be  modelled  as  a  proximity  engagement  (see  Section 
D.2). 

2)  Weapons  that  emit  energy  for  a  certain  amount  of  time,  typically  the  start  and  end  time  are  under 
user  control.  For  example  sound  waves  or  micro  waves  can  be  generated  by  a  weapon  when  it  is 
activated  and  the  energy  emission  stops  when  the  weapon  is  deactivated  (trigger  released).  When  the 
emission  stops,  also  the  influence  stops.  The  emission  of  this  type  of  weapons  requires  a  new 
engagement  definition. 

When  energy  weapons  emit  energy  during  a  certain  timeframe,  it  is  important  to  note  that  many  of  the 
engagement  parameters  can  change  during  the  engagement.  For  example,  the  shooter  and  target(s)  can  move, 
the  direction  of  the  weapon  can  change  and  maybe  even  the  energy  level  can  change. 


Table  E-15:  Energy  Weapons  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Shooter  ID 

MONITORING 

ID 

15,000 

- 

Shooter  location  (x,  y,  z), 

plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub-decimeter 

Shooter  velocity  (vector),  plus 
accuracy  indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

Weapon  type 

MONITORING 

Category 

- 

Weapon  ID 

ANALYSIS 

ID 

- 

Shooter  weapon  mode 

TARGETING 

MONITORING 

Category 

- 

Weapon  direction/angle  (vector), 
plus  accuracy  indicator 

TARGETING 

+/-  10% 
compared  to 
actual  weapon 

Energy  type 

DAMAGE 

CALCULATION 

Category 

Energy  level 

DAMAGE 

CALCULATION 

Effect  volume 

DAMAGE 

CALCULATION 

Meter 

Meter 

Activation  time 

TARGETING 

MONITORING 

Seconds 

Second 

Deactivation  time 

TARGETING 

MONITORING 

Seconds 

Second 

Engagement  time 

MONITORING 

Seconds 

Second 

Engagement  duration 

DAMAGE 

CALCULATION 

Seconds 

Second 

Terrain 

TARGETING 

DAMAGE 

CALCULATION 

Meter 

Sub-decimeter 

STO-TR-MSG-098 


E  -  25 


ANNEX  E  -  El:  DO  ENGAGEMENT 


organization 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Atmospheric  data 

TARGETING 

- 

Affected  DO(s)  ID 

DAMAGE 

CALCULATION 

ID 

- 

Affected  DO(s)  location  (x,  y,  z), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub-decimeter 

Affected  DO(s)  velocity  (vector), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

Point  of  impact 

DAMAGE 

CALCULATION 

Meter 

Sub-decimeter 

Shooter  ID 

The  unique  identifier  to  identify  the  DO  that  causes  the  engagement. 

Shooter  Location  (x,  y,  z) 

The  three-dimensional  position  of  the  shooter  during  the  engagement. 

Shooter  Velocity  (Vector) 

The  three-dimensional  speed  of  the  shooter  during  the  engagement,  for  targeting  and  monitoring  purposes. 
Weapon  Type 

The  type  of  weapon  that  is  used  to  cause  the  engagement,  mainly  used  for  monitoring  purposes. 

Weapon  ID 

The  unique  identification  of  the  weapon  that  was  used  to  cause  the  engagement. 

Shooter  Weapon  Mode 

The  mode  of  the  weapon  during  the  engagement.  It  contains  for  example  the  settings  of  a  fire  control 
computer,  the  used  sighting  device,  etc. 

Weapon  Direction/Angle 

The  direction/angle  of  the  weapon,  and  thus  that  of  the  energy  beam,  during  the  engagement,  used  for 
targeting.  If  the  energy  beam  is  very  narrow,  e.g.,  a  laser  beam,  the  accuracy  needs  to  be  very  high.  If  the 
energy  beam  covers  an  arc,  the  accuracy  can  be  1  degree. 

Energy  Type 

The  type  of  the  emitted  energy,  used  for  damage  calculation  and  monitoring.  It  is  more  specific  than  only  the 
category.  Like  for  example  “sound”  or  “light”,  but  contains  for  example  the  used  frequency  or  frequency 
range  of  sound  or  light  energy. 


E  -  26 


STO-TR-MSG-098 


ANNEX  E  -  El:  DO  ENGAGEMENT 


Energy >  Level 

It  is  possible  that  the  shooter  can  set  or  control  the  level  of  the  emitted  energy,  even  during  the  engagement. 
This  parameter  specifies  the  power  or  intensity  of  the  emitted  energy. 

Effect  Volume 

The  three-dimensional  space  in  which  the  emitted  energy  has  an  effect.  Typically  it  will  be  a  beam  or  a  cone, 
having  a  direction,  width,  height  and  length.  In  practice  a  beam  of  energy  generally  will  not  have  clear  cut 
edges,  but  for  simulation  purposes  this  will  suffice. 

Activation  Time 

The  instance  in  time  when  the  energy  weapon  is  activated  and  starts  emitting  energy.  It  is  used  for  targeting 
and  monitoring  purposes. 

Deactivation  Time 

The  instance  in  time  when  the  energy  weapon  is  deactivated  and  stops  emitting  energy.  It  is  used  for 
targeting  and  monitoring  purposes. 

Engagement  Time 

The  instance  in  time  when  the  DO(s)  are  engaged,  each  upon  colliding  with  the  effect  volume.  Depending  on 
the  type  of  energy,  the  effect  will  be  immediate,  delayed  or  increase  over  time  the  longer  the  DO  stays  within 
the  energy  field. 

Engagement  Duration 

The  duration  of  time  the  affected  DO(s)  are  exposed  to  the  energy  field. 

Terrain 

The  terrain  is  an  important  factor  for  targeting  and  damage  calculations. 

Atmospheric  Data 

Atmospheric  conditions  can  influence  the  effect  of  energy  weapons. 

Affected  DO (s)  ID 

The  unique  identification  of  the  DO(s)  that  are  affected  by  the  engagement. 

Affected  DO(s)  Location 

The  three-dimensional  location(s)  of  the  affected  DO(s)  during  the  engagement,  used  for  targeting  and 
monitoring  purposes. 

Affected  DO(s)  Velocity 

The  three-dimensional  speed  of  the  affected  DO(s),  used  for  targeting  and  monitoring  purposes. 

Point  of  Impact 

The  location  on  the  target  DO  where  the  engagement  affects  the  target.  In  case  of  a  narrow  beam  of  energy, 
the  accuracy  needs  to  be  sub-decimeter.  In  case  of  a  wide  beam  of  energy,  the  side  of  the  target  DO  will 
suffice. 
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E.6  NON-LETHAL  (OR  LESS  THAN  LETHAL)  WEAPONS 

The  purpose  of  NLW  is  to  temporarily  incapacitate  the  target,  so  the  big  difference  with  other  types  of 
weapons  is  that  their  effects  are  temporal,  they  do  not  require  an  explicit  repair  or  heal  action.  NLW  can 
partially  or  even  totally  incapacitate  the  target,  but  when  terminating  the  engagement  or  after  a  limited 
amount  of  time,  the  effect  degrades  or  wears  off  completely.  This  automatic  change  of  the  operational  state 
of  a  DO  is  not  part  of  the  engagement,  but  it  is  important  to  realise  that  the  implementation  of  NLW  requires 
an  extension  of  the  simulation  model  of  a  DO,  to  take  an  incapacitation  period  into  account. 

With  this  mechanism  also  another  effect  can  be  simulated,  namely  the  temporal  incapacitation  of  personnel 
that  is  subject  to  a  near  miss  of  a  large  calibre  round  or  the  pressure  wave  of  a  nearby  explosion.  This  temporal 
incapacitation  represents  the  shock  personnel  suffers  from  when  exposed  to  these  types  of  event. 

There  are  many  types  of  NLW,  however,  their  use  can  be  modelled  by  the  mechanisms  and  datasets 
described  in  the  previous  sections.  For  example,  fired  projectiles  like  rubber  bullets,  bean  bags  or  even  spider 
webs  can  be  implemented  as  a  contact  engagement,  requiring  no  additional  parameters,  but  only  a  different 
ammunition  ID  and  maybe  a  different  weapon  ID.  Likewise,  the  firing  of  an  electro  shock  gun  can  be 
modelled  as  a  contact  engagement,  where  the  charge  can  be  defined  as  ammunition  ID.  A  flash-bang  grenade 
requires  exactly  the  same  dataset  as  a  lethal  hand  grenade,  but  based  on  its  ammunition  ID  it  will  result  in  a 
different  effect.  Tear  gas  and  other  non-lethal  substances  can  be  modelled  as  categories  of  CBRN  weapons. 
Laser  dazzlers,  sound  waves  and  microwaves  are  energy  weapons. 

New  developments  of  different  types  of  NLW  in  the  future  may  lead  to  an  adaptation  of  the  current  types  of 
engagements  and  their  associated  datasets. 


E.7  JAMMERS 

Jammers  are  devices  that  generate  a  “bubble”  of  electronic  noise  that  disturbs  the  signal  by  which  a  Radio 
Controlled  1ED  (RC-1ED)  is  initiated,  thereby  preventing  it  from  detonating.  Also,  as  side  effect,  a  jammer 
can  disturb  the  radio  communication  of  DOs  that  are  located  in  the  generated  bubble. 

Generally,  jammers  are  associated  with  a  DO,  they  are  built  in  a  vehicle  or  carried  by  a  dismounted  soldier. 
However,  it  is  also  possible  to  place  a  portable  jammer  on  a  certain  location  in  the  field,  for  example  when 
investigating  an  1ED.  Therefore,  jammers  can  be  modelled  as  a  property  of  a  DO  (when  built  into  it)  or  as  a 
separate  DOs  themselves  (portable  jammers  that  can  be  placed  in  the  environment). 

E.7.1  Jammer  Activation  and  Deactivation 

Table  E-16:  Jammer  Activation  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Carrier  ID 

MONITORING 

ID 

15,000 

- 

Jammer  ID 

MONITORING 

ID 

- 

Jammer  volume 

TARGETING 

Meter 

1000 

Meter 

Jammer  frequency  list 

DAMAGE 

CALCULATION 

Hz 

- 

Jamming  mode 

TARGETING 

MONITORING 

- 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Activation  time 

TARGETING 

Seconds 

Second 

MONITORING 

Carrie r  ID 

The  identification  of  the  DO  that  carries  a  jammer. 

Jammer  ID 

If  a  jammer  is  modelled  as  a  separate  DO,  it  has  its  own  ID  and  its  own  location. 

Jammer  Volume 

The  three-dimensional  volume  of  the  jammer,  modelled  as  a  sphere  with  a  specific  radius.  If  the  jammer  is 
off,  the  volume  will  be  zero.  In  reality  the  volume  of  a  jammer  is  not  a  sphere,  but  a  complex  volume 
depending  on  many  different  factors,  amongst  others  shielding  objects,  such  as  the  human  body  when  the 
jammer  is  carried  in  a  backpack.  For  training  purposes  it  suffices  to  model  the  volume  as  a  sphere. 

Jammer  Frequency  List 

The  specification  of  the  frequencies  that  are  jammed  by  the  jammer. 

Jamming  Mode 

The  mode  in  which  the  jammer  is  in. 

Activation  Time 

The  instance  in  time  when  the  jammer  is  activated  (switched  on). 

Deactivation  Time 

The  instance  in  time  when  the  jammer  is  deactivated  (switched  off). 


Table  E-17:  Jammer  Deactivation  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Carrier  ID 

MONITORING 

ID 

15,000 

- 

Jammer  ID 

MONITORING 

ID 

- 

Deactivation  time 

TARGETING 

Seconds 

Second 
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E.7.2  Jammer  Engagements 


Table  E-18:  Jammer  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Carrier  ID 

MONITORING 

ID 

15,000 

- 

Jammer  ID 

MONITORING 

ID 

- 

Affected  DO(s)  ID 

DAMAGE 

CAFCUFATION 

ID 

- 

Affected  DO(s) 
location 

DAMAGE 

CAFCUFATION 

Meter 

- 

Terrain 

TARGETING 

- 

Affected  DO (s)  ID 

The  identification  of  the  DO(s)  that  are  affected  by  the  engagement,  i.e.  are  inside  the  bubble  of  the  jammer. 
It  can  either  be  RC-IEDs  that  are  inhibited  from  detonating  on  command  or  DOs  whose  radio  communication 
is  hampered  when  their  frequency  is  covered  by  the  frequencies  of  the  jammer. 


Affected  DO(s)  Position 

The  location(s)  of  the  affected  DO(s). 


Terrain 

The  terrain  can  influence  the  shape  of  the  bubble,  objects  in  the  terrain  can  diminish  or  shield  the  bubble. 


E.8  C4I  INTERROGATION  AND  THREAT  WARNING  SYSTEMS 

Weapon  systems  and  personnel  can  be  equipped  with  systems  that  allow  them  to  recognise  or  identify 
friendly  entities,  distinguishing  them  from  other  or  hostile  entities.  Terms  used  are  Combat  Identification 
systems  or  Identification  Friend  or  Foe  (IFF)  systems.  Comparable  systems,  but  with  a  different  purpose, 
are  systems  that  can  detect  when  they  are  interrogated  or  “hit”  by  an  energy  emission,  such  as  a  (hostile) 
laser  beam.  Generally,  these  operational  systems  can  be  used  in  the  live  training  environment.  When  threat 
warning  systems  can  automatically  initiate  counter  measures,  it  may  be  required  for  safety  purposes  to 
inhibit  the  actual  execution  of  these  counter  measures. 

From  a  training  system  perspective,  these  systems  are  considered  as  operational  C4I  systems,  which  do  not 
require  the  definition  and  implementation  of  simulated  engagements.  However,  it  is  required  that  the  active 
use  of  interrogation  systems  (when  were  what  codes  transmitted  by  whom  and  received  by  whom)  and  the 
activation  of  threat  warning  systems  (when  were  what  signals  received  by  whom  and  what  warnings  were 
issued)  are  logged  and  made  available  for  monitoring  and  analysis  purposes. 


E.9  REPAIR  AND  MEDICAL  ACTIVITIES 

During  operations  (minor)  damages  to  vehicles  and  large  weapon  systems  can  be  repaired  in  the  field,  either 
by  the  crew  themselves  or  by  combat  service  support  units.  When  repair  is  not  possible  in  the  field,  damaged 
equipment  can  be  recovered  and  transported  to  a  higher  level  repair  facility. 
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Similarly,  wounded  personnel  can  be  treated  in  the  field  by  other  (medical)  personnel.  When  treatment 
cannot  be  executed  or  completed  in  the  field,  wounded  personnel  is  transported  or  evacuated  to  higher 
echelon  medical  facilities. 

These  repair  and  medical  activities  greatly  influence  the  tactical  operation:  they  consume  resources  for 
execution,  they  require  protection,  they  take  time  and  the  results  of  the  activities  influence  the  combat  power 
of  a  unit.  Therefore  it  is  important  that  these  functionalities  can  be  trained  in  the  context  of  live  tactical 
training  exercises.  The  primary  training  audiences  of  these  activities  might  not  even  be  the  performers 
themselves,  but  the  command  and  control  levels  that  direct  the  operation. 

Higher  echelon  facilities,  such  as  repair  centres  or  field  hospitals  (role  1  and  higher)  are  generally  not  part  of 
tactical  exercises.  At  least  there  is  no  requirement  to  simulate  or  instrument  them  in  the  live  environment; 
those  functionalities,  if  required,  can  be  simulated  by  EXCON. 

E.9.1  Equipment  -  Repair  Activities 

The  basis  for  repair  activities  is  the  simulated  damage  statuses  of  the  DOs,  possibly  complemented  by 
additional  status  information  that  can  be  retrieved  for  diagnosis.  The  more  detailed  the  status  information  is, 
the  more  distinction  can  be  made  in  the  associated  repair  activities.  For  example,  if  the  status  of  a  DO  is 
limited  to  “operational”,  “mobility  kill”  and  “total  kill”,  a  repair  activity  cannot  be  more  detailed  than  simply 
to  restore  the  mobility.  However,  if  the  status  can  make  a  distinction  between  a  mobility  kill  due  to  engine 
failure  or  a  track  or  wheel  fallen  off,  a  repair  activity  can  be  more  specific.  Similarly,  a  distinction  can  be 
made  between  who  is  capable  or  authorised  to  execute  the  repair.  In  the  example  of  a  detailed  mobility  kill, 
the  crew  coidd  repair  the  track  or  wheel  fallen  off  themselves,  while  a  recovery  team  is  required  to  change 
the  engine. 

In  order  to  enable  the  implementation  of  repair  activities,  it  is  required  that  players  can  diagnose  the 
sustained  damage  of  a  DO  and  can  interact  with  the  DO  to  change  the  degraded  status  by  means  of  a 
simulated  repair  activity.  How  these  interactions  are  physically  implemented  is  not  prescribed.  But  one  can 
for  example  think  of  a  display  in  or  on  a  vehicle  to  read  off  the  damage  status  and  select  the  proper  repair 
activity.  For  weapon  systems  that  have  an  advanced  C4I  system  that  can  register  the  status  of  the  weapon 
system,  the  simulated  damage  state  can  be  communicated  through  that  C4I  system. 

Of  course  the  physical  actions  to  perform  the  repair  do  not  need  or  even  cannot  be  executed  in  the  live 
training  environment.  Instead  it  is  sufficient  that  after  initiating  the  repair  activity,  a  certain  repair  time  is 
taken  into  account.  Only  after  that  time  period  has  finished,  the  repair  is  considered  to  have  taken  place 
successfully  and  the  damage  status  will  be  changed.  During  the  repair  time  the  damage  status  and  the 
associated  limitations  for  the  vehicle  and  crew  will  stay  in  effect. 

Some  users  of  live  training  systems  can  choose  to  require  additional  functionality  regarding  repair  activities 
that  is  currently  not  part  of  the  UCATT  standard.  The  current  UCATT  requirements  are  considered  to  satisfy 
the  relevant  training  objectives.  Such  additional  functionality  could  be  to  implement  conditions  that  must  be 
satisfied  during  the  repair  activity  to  be  effective,  for  example  when  the  repairing  DO  is  killed,  the  repair  is 
cancelled.  Or  when  the  repairing  DO  and  the  DO  to  be  repaired  are  separated  more  than  say  50  meters,  the 
repair  is  also  cancelled  (to  prevent  that  one  repairer  can  activate  multiple  repair  activities  simultaneously, 
which  he  couldn’t  do  in  reality).  When  a  repair  activity  is  cancelled,  one  can  then  decide  to  require  that  a 
new  repair  activity  starts  the  repair  process  all  over  again  or  shoidd  continue  where  the  previous  repair 
activity  left  off. 

It  is  currently  assessed  that  it  suffices  to  record  only  the  ID  of  one  repairing  DO,  this  can  be  the  ID  of  the 
person  who  initiates  the  repair  activity  or  the  ID  of  the  vehicle  (unit)  that  person  belongs  to.  In  reality, 
a  repair  activity  can  be  executed  by  multiple  persons  working  as  a  team,  for  example  changing  a  vehicle 
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engine  in  the  field  generally  involves  the  whole  crew  of  a  repair  vehicle.  Administrating  the  IDs  of  all 
persons  involved  in  the  repair  activity  is  currently  not  required.  If  that  would  be  required,  one  can  even 
decide  that  the  number  of  persons  working  on  the  repair  influences  the  repair  time  (the  more  the  faster)  or 
influences  the  repair  result  (for  example  changing  an  engine  cannot  be  done  by  one  person  alone).  But  as 
stated,  since  repair  activities  probably  can  only  be  performed  with  a  low  level  of  fidelity  in  a  live  training 
environment,  such  requirement  are  considered  to  be  outside  the  scope  of  the  training  objectives. 

Repair  activities  in  the  field  that  must  be  supported  by  the  training  system  can  be  performed  by: 

•  The  crew  of  the  damaged  vehicle.  The  repair  activities  are  limited  to  those  activities  that  the  crew 
can  perform  by  themselves  in  reality.  Since  this  is  only  a  very  limited  set  of  activities,  this  possibility 
has  a  low  priority. 

•  The  crew  of  a  recovery  vehicle.  They  have  more  knowledge,  skills,  tools  and  spare  parts  than  the 
crew  of  the  damaged  vehicle  and  therefore  they  can  repair  more  serious  damage. 

•  If  the  damage  cannot  be  repaired  in  the  field,  the  damaged  vehicle  can  be  transported  to  a  repair 
facility.  This  recovery  can  be  executed  in  the  live  environment,  without  need  for  special  training 
equipment  functionality. 

•  Members  of  EXCON,  including  O/Cs  in  the  field.  EXCON  must  have  the  possibility  to  initiate  a 
repair  activity,  either  taking  into  account  the  repair  time  it  would  take  another  actor  (the  crew 
themselves  or  the  crew  of  a  recovery  vehicle),  or  instantaneously.  This  latter  possibility  is  useful  to 
make  optimal  use  of  the  training  time. 

Note  that  for  analytical  and  monitoring  purposes  it  is  useful  to  make  a  distinction  between  an 
instantaneous  EXCON  repair  and  an  EXCON  reset.  Although  the  effects  are  exactly  the  same  (both 
can  result  in  immediately  changing  the  damage  status),  an  EXCON  repair  is  within  the  tactical 
context  of  the  exercise,  while  an  EXCON  reset  is  an  intervention  outside  that  scope,  e.g.,  due  to  a 
(sub)system  failure,  therefore  the  data  in  the  generated  reports  will  be  treated  differently. 

It  is  assumed  that  one  repair  activity  will  repair  only  one  type  of  damage.  Multiple  damages  require 
multiple  repair  activities  that  coidd  be  executed  simultaneously  or  successively.  For  example,  to  repair  a 
communication  kill  and  a  mobility  kill,  requires  a  “repair  communication  system”  and  a  “repair  engine”. 
Those  repair  activities  can  be  executed  by  the  same  repair  DO  or  by  two  separate  repair  DOs. 


Table  E-19:  Repair  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Repair  DO  ID 

ENGAGING 

MONITORING 

ID 

15,000 

- 

Repair  DO  location  (x,  y,  z), 
plus  accuracy  indicator 

ENGAGING 

MONITORING 

Meter 

World 

coordinate 

Meter 

Repair  activity  ID 

EFFECT 

CALCULATION 

MONITORING 

ID 

100 

Engagement  time 

MONITORING 

Seconds 

Second 

Repair  duration 

EFFECT 

CALCULATION 

MONITORING 

Number 

43,200 
seconds 
(12  hours) 

Second 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Affected  DO  ID 

ENGAGING 

MONITORING 

ID 

- 

Affected  DO  location  (x,  y,  z, 

ENGAGING 

Meter 

World 

Meter 

plus  accuracy  indicator 

MONITORING 

coordinate 

Repair  DO  ID 

The  ID  of  the  DO  that  performs  the  repair  activity.  This  is  required  to  determine  if  the  DO  is  permitted  or  has 
the  capability  to  perform  the  repair  activity.  Also  for  analytical  and  monitoring  purposes  the  IDs  of  the 
involved  DOs  are  required. 

Repair  DO  Location 

The  location  of  the  repair  DO,  mainly  used  for  monitoring  purposes,  but  conditions  can  be  checked  that  the 
repair  DO  must  be  in  the  direct  vicinity  of  the  DO  to  be  repaired. 

Repair  Activity  ID 

The  activity  identification  of  the  initiated  repair  activity. 

Engagement  Time 

The  instance  in  time  when  the  repair  activity  starts  and  is  mainly  used  for  monitoring  purposes. 

Repair  Duration 

The  duration  in  seconds  of  how  long  the  repair  activity  will  take  to  become  in  effect.  This  can  be  zero, 
to  immediately  change  the  damage  status  of  the  affected  DO.  In  practice,  the  duration  of  a  repair  activity  is 
generally  measured  in  minutes,  rather  than  seconds. 

Affected  DO  ID 

The  ID  of  the  DO  to  be  repaired. 

Affected  DO  Location 

The  location  of  the  DO  to  be  repaired. 

There  will  be  a  mapping  of  which  (type  of)  DO  are  allowed  to  perform  what  repair  activities  on  what  type  of 
damaged  DO.  Those  permissions  are  considered  as  properties  of  the  DO  that  wants  to  perform  a  repair 
activity  and  are  therefore  not  part  of  the  engagement  data.  If  a  DO  has  insufficient  permission  to  perform  a 
particular  repair  activity,  either  he  cannot  select  or  initiate  such  activity  or  the  activity  will  have  no  effect. 

E.9.2  Personnel  -  Medical  Treatment 

Medical  treatment  of  wounded  personnel  is  from  the  perspective  of  the  training  system  quite  similar  to  repair 
activities  regarding  damaged  equipment.  Also  here  the  health  status  of  the  DO,  possibly  complemented  by 
additional  status  information  that  can  be  retrieved  for  diagnosis  is  the  basis  for  medical  treatment.  The  more 
detailed  the  information  is,  the  more  distinction  can  be  made  in  the  associated  medical  activities. 
And  likewise,  a  distinction  can  be  made  between  who  is  capable  or  authorised  to  execute  a  medical 
treatment. 
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There  is  one  big  difference  with  repairing  equipment.  Given  the  level  of  detail  in  the  training  system,  a 
damage  to  a  piece  of  equipment  will  generally  not  get  worse  by  itself,  to  change  the  system  state  of  a  DO  an 
external  interaction  or  engagement  is  required.  Repair  activities  aim  to  improve  the  status  of  a  DO. 

For  wounded  personnel  however,  in  reality  when  a  wound  is  not  treated,  the  situation  will  deteriorate  and  the 
victim  will  lose  capabilities  and  can  eventually  die.  When  the  training  system  supports  a  rich  set  of  health 
statuses  and  associated  diagnostic  data  for  personnel,  it  is  also  logical  that  there  is  a  simulation  model  that 
determines  such  degradation  of  the  health  status.  The  purpose  of  medical  treatment  in  the  field  is  to  stop  or 
slow  the  deterioration  of  the  health  of  a  wounded  person.  Actual  healing  of  a  wound  will  generally  require 
medical  facilities  and  will  take  more  time  than  is  available  in  the  exercise.  It  should  also  be  possible  for  an 
affected  DO’s  health  to  deteriorate  when  the  wrong  treatment  is  given,  even  faster  than  when  no  action  is 
taken  at  all.  Therefore  a  treatment  can  have  a  negative  effect. 

In  order  to  enable  the  implementation  of  medical  treatment,  it  is  required  that  players  can  diagnose  the  health 
status  of  personnel  DOs  and  can  interact  with  the  wounded  DOs  to  change  the  health  status  by  means  of  a 
simulated  medical  activity.  How  these  interactions  are  physically  implemented  is  not  prescribed. 

The  physical  activities  to  treat  a  wounded  person  do  not  need  or  even  cannot  be  executed  in  the  live  training 
environment.  It  is  sufficient  that  relevant  timing  conditions  are  taken  into  account  (e.g.  pressure  must  be 
applied  for  a  certain  period)  in  order  to  consider  the  treatment  as  successful. 

Medical  treatment  activities  in  the  field  that  must  be  supported  by  the  training  system  can  be  performed  by: 

•  The  wounded  DO  itself  (care  under  fire).  The  associated  medical  activities  are  limited  to  those 
activities  that  a  person  can  perform  by  himself  in  reality,  such  as  taking  medication  or  applying 
pressure  to  stop  a  bleeding. 

•  Any  non-medical  personnel,  also  they  are  only  capable  to  perform  very  basic  medical  activities. 

•  Medically  trained  personnel.  They  have  more  knowledge,  skills  and  tools  and  therefore  can  perform 
more  complicated  medical  activities.  They  also  can  decide  on  medical  evacuation  or  transportation 
to  a  medical  facility.  This  transportation  can  be  executed  in  the  live  environment,  without  need  for 
special  training  equipment  functionality. 

•  Members  of  EXCON,  including  O/Cs  in  the  field.  EXCON  must  have  the  possibility  to  initiate  a 
medical  treatment,  either  taking  into  account  the  treatment  time  it  would  take  another  actor  or 
instantaneously.  For  analytical  and  monitoring  purposes  it  is  useful  to  make  a  distinction  between  an 
instantaneous  medical  treatment  and  an  EXCON  reset. 


Table  E-20:  Medical  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Medic  DO  ID 

ENGAGING 

MONITORING 

ID 

15,000 

- 

Medic  DO  location  (x,  y,  z), 
plus  accuracy  indicator 

ENGAGING 

MONITORING 

Meter 

World 

coordinate 

Meter 

Medical  activity  ID 

EFFECT 

CALCULATION 

MONITORING 

ID 

100 

Engagement  time 

MONITORING 

Seconds 

Second 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Treatment  duration 

EFFECT 

CAECUEATION 

MONITORING 

Number 

43,200 
seconds 
(12  hours) 

Second 

Affected  DO  ID 

ENGAGING 

MONITORING 

ID 

- 

Affected  DO  location  (x,  y,  z), 
plus  accuracy  indicator 

ENGAGING 

MONITORING 

Meter 

World 

coordinate 

Meter 

Medic  DO  ID 

The  ID  of  the  DO  that  performs  the  medical  activity. 

Medic  DO  Location 

The  location  of  the  medic  DO,  mainly  used  for  monitoring  purposes,  but  conditions  can  be  checked  that  the 
medic  DO  must  be  and  stay  during  the  medical  treatment  in  the  direct  vicinity  of  the  wounded  DO. 

Medical  Activity  ID 

The  activity  identification  of  the  performed  medical  activity. 

Engagement  Time 

The  instance  in  time  when  the  medical  treatment  starts  and  is  mainly  used  for  monitoring  purposes. 
Treatment  Duration 

The  duration  in  seconds  of  how  long  the  medical  activity  will  take  to  become  in  effect. 

Affected  DO  ID 

The  ID  of  the  DO  to  be  treated. 


Affected  DO  Location 

The  location  of  the  DO  to  be  treated. 

There  will  be  a  mapping  of  which  (type  of)  DO  are  allowed  to  perform  what  medical  activities  on  what 
wounds.  Those  permissions  are  considered  as  properties  of  the  DO  that  wants  to  perform  a  medical  activity 
and  are  therefore  not  part  of  the  engagement  data.  If  a  DO  has  insufficient  permission  to  perform  a  particular 
medical  activity,  either  he  cannot  select  or  initiate  such  activity  or  the  activity  will  have  no  effect. 


E.10  LOGISTICS 

During  actual  operations  supplies  are  consumed  and  also  replenished.  Several  categories  of  supply  are 
distinguished1: 


1  Source:  APP-6(C),  NATO  joint  military  symbology. 
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•  Class  I  -  Items  which  are  consumed  by  personnel  or  animals  at  the  approximately  uniform  rate, 
irrespective  of  local  changes  in  combat  or  terrain  conditions.  Food  is  a  typical  example. 

•  Class  II  -  Supplies  for  which  allowances  are  established  by  tables  of  organisation  and  equipment. 

•  Class  III  -  Petrol,  oil  and  lubricants. 

•  Class  IV  -  Supplies  for  which  initial  issue  allowances  are  not  prescribed  by  approved  issue  tables. 
Normally  such  supplies  include  fortification  and  construction  materials,  as  well  as  additional 
quantities  of  items  identical  to  those  authorised  for  initial  issue  (Class  II),  such  as  additional 
vehicles. 

•  Class  V  -  Ammunition,  explosives  and  chemical  agents  of  all  types. 

For  tactical  exercises  mainly  classes  III  and  V  are  relevant: 

•  Class  III  supplies  are  not  simulated,  but  the  real  materials  are  used  in  realistic  quantities.  There  is  no 
requirement  for  the  training  system  to  register  or  analyse  the  consumption  and  resupply  of  fuel. 

•  Class  V  supplies  are  simulated  and  it  is  required  to  register  and  analyse  ammunition  consumption 
and  resupply. 

•  It  is  noted  that  medical  treatment  also  consumes  material,  but  there  is  no  requirement  to  simulate 
such  medical  materials  and  thus  there  is  no  requirement  for  resupply. 

Resupply  activities  that  must  be  supported  by  the  training  system  can  be  performed  by: 

•  A  resupply  vehicle.  Such  a  vehicle  is  equipped  with  specific  types  of  ammo  in  certain  quantities. 
A  resupply  activity  will  reduce  the  stock  available  for  subsequent  resupplies.  In  reality  resupply  of 
ammo  will  take  (some)  time,  this  must  also  be  simulated. 

•  Members  of  EXCON,  including  O/Cs  in  the  field.  EXCON  must  have  the  possibility  to  initiate  a 
resupply  activity,  either  taking  into  account  the  resupply  time  it  would  take  a  resupply  vehicle  or 
instantaneously.  For  analytical  and  monitoring  purposes  it  is  useful  to  make  a  distinction  between  an 
instantaneous  resupply  activity  and  an  EXCON  reset  of  the  (initial)  supplies. 

Resupply  activities  that  can  take  place  in  reality,  but  need  not  to  be  supported  by  the  training  system: 

•  Resupply  of  blank  ammunition.  This  ammunition  exists  in  reality  and  can  therefore  be  physically 
distributed  without  interaction  with  the  training  system.  This  applies  for  example  to  ammunition  of 
small  calibre  weapons. 

•  Redistribution  of  supplies  by  the  elements  of  a  tactical  unit  amongst  themselves.  For  example  tank 
crews  of  a  platoon  redistributing  shells  within  the  platoon. 

•  Resupply  in  special  resupply  depots.  Such  large  scale  resupply  in  specific  logistical  areas  can  be 
performed  by  EXCON. 

To  enable  the  implementation  of  resupply  of  simulated  ammunition,  it  is  required  that  players  can  interact 
with  a  DO  to  request  the  current  stock  of  simulated  ammunition  of  that  DO  and,  when  authorised,  to  change 
the  stock.  How  these  interactions  are  physically  implemented  is  not  prescribed. 
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Table  E-21:  Logistic  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Supplier  DO  ID 

ENGAGING 

MONITORING 

ID 

15,000 

- 

Supplier  DO  location  (x,  y,  z), 
plus  accuracy  indicator 

ENGAGING 

MONITORING 

Meter 

World 

coordinate 

Meter 

Supply  activity  ID 

EFFECT 

CALCULATION 

MONITORING 

ID 

100 

Ammunition  type 

EFFECT 

CALCULATION 

MONITORING 

Category 

Supply  quantity 

EFFECT 

CALCULATION 

MONITORING 

Number 

10,000 

1 

Engagement  time 

MONITORING 

Seconds 

Second 

Supply  duration 

EFFECT 

CALCULATION 

MONITORING 

Number 

3,600 
(1  hour) 

Second 

Affected  DO  ID 

ENGAGING 

MONITORING 

ID 

- 

Affected  DO  location  (x,  y,  z), 
plus  accuracy  indicator 

ENGAGING 

MONITORING 

Meter 

World 

coordinate 

Meter 

Supplier  DO  ID 

The  ID  of  the  DO  that  performs  the  resupply  activity. 

Supplier  DO  Location 

The  location  of  the  supplying  DO,  mainly  used  for  monitoring  purposes,  but  conditions  can  be  checked  that 
the  supplying  DO  must  be  and  stay  during  the  resupply  activity  in  the  direct  vicinity  of  the  supplied  DO. 

Supply  Activity  ID 

The  activity  identification  of  the  performed  resupply  activity.  A  distinction  can  be  made  between  giving  or 
taking  supplies,  resulting  in  a  positive  or  negative  value  of  the  parameter. 

Ammunition  Type 

The  type  of  ammunition  being  resupplied.  If  more  than  one  type  of  ammunition  is  supplied,  then  multiple 
engagements  are  required,  one  for  each  ammo  type. 

Supply  Quantity 

The  amount  of  shells  involved  in  the  resupply  activity. 
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Engagement  Time 

The  instance  in  time  when  the  resupply  activity  starts  and  is  mainly  used  for  monitoring  purposes. 
Supply  Duration 

The  duration  in  seconds  of  how  long  the  resupply  activity  will  take  to  become  in  effect. 

Affected  DO  ID 

The  ID  of  the  DO  to  be  resupplied. 

Affected  DO  Location 

The  location  of  the  DO  to  be  resupplied. 


E.ll  O/C  IMITATED  ENGAGEMENTS 

It  is  required  that  an  O/C  can  interact  with  other  DOs,  as  if  he  were  a  normal  player,  simulating  their 
engagements.  This  capability  is  required  for  training  purposes  of  the  affected  DO,  within  the  context  of  the 
tactical  training  exercise.  Examples  of  this  situation  are  exposing  the  weak  spots  of  an  attack  or  defence, 
by  simulating  fire  from  a  dug  in  enemy  tank  or  an  enemy  sniper,  or  stepping  in  when  the  trainee  interactions 
are  not  delivering  the  required  results  in  the  training  context  for  whatever  reasons  (e.g.,  incapable  trainees, 
system  malfunctions). 

If  for  “normal”  E 1  engagements  the  affected  DO  is  notified  who  or  what  caused  the  interaction,  in  this  case 
he  will  not  be  notified  it  was  an  O/C  or  EXCON  interaction,  but  he  will  be  provided  with  imitated 
information,  such  as  for  example  the  party  of  the  shooter  (e.g.,  BLUEFOR,  REDFOR,  NEUFOR)  and  the 
ammunition  type.  Since  an  O/C  has  no  party  (he  is  impartial)  and  should  be  able  to  simulate  any  type  of 
weapon,  he  must  specify  these  values  before  the  engagement. 

For  monitoring  purposes,  the  ID  of  the  O/C  will  be  part  of  the  engagement  to  distinguish  between  O/C  and 
other  DO  engagements.  Although  the  O/C  will  simulate  an  engagement,  operational  conditions  or  restrictions 
regarding  associated  skills  and  drills  (such  as  for  example  time,  distance,  speed  of  the  shooter,  accuracy  etc.) 
will  not  apply,  because  it  is  not  the  objective  to  train  the  O/C,  but  to  deliberately  expose  a  DO  to  the 
engagement. 

The  tables  below  are  derived  from  the  engagement  tables  described  in  the  previous  paragraphs.  Certain 
parameters  have  been  omitted  and  only  the  additional  O/C  specific  parameters  are  highlighted  (in  orange) 
and  explained. 

E.ll.l  O/C  Imitated  Contact  and  Proximity  Engagements 


Table  E-22:  O/C  Imitated  Contact  and  Proximity  Engagement  Dataset  (Including  Missiles). 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

O/C  ID 

MONITORING 

ID 

15,000 

- 

O/C  location  (x,  y,  z), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub-decimeter 

Imitated  party  ID 

MONITORING 

Category 

- 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Imitated  weapon  type 

MONITORING 

Category 

- 

Weapon  direction/angle  (vector), 
plus  accuracy  indicator 

TARGETING 

VERY  HIGH 

Imitated  ammunition  type 

DAMAGE 

CALCULATION 

Category 

- 

Duration  of  flight 

TARGETING 

Seconds 

Micro-seconds 

Engagement  range 

DAMAGE 

CALCULATION 

MONITORING 

Meter 

Meter 

Detonation  location  (x,  y,  z),  plus 
indicator  of  accuracy 

DAMAGE 

CALCULATION 

MONITORING 

Meter 

Sub-decimeter 

Effect  direction/angle  (vector)  at 
the  moment  of  detonation 

DAMAGE 

CALCULATION 

HIGH 

Effect  volume 

DAMAGE 

CALCULATION 

Meter 

Meter 

Terrain 

TARGETING 

DAMAGE 

CALCULATION 

Meter 

Sub-decimeter 

Affected  DO(s)  ID 

DAMAGE 

CALCULATION 

ID 

- 

Affected  DO(s)  location  (x,  y,  z), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub-decimeter 

Affected  DO(s)  velocity  (vector), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

Time  of  start  of  the  engagement 

(trigger  time), 

plus  accuracy  indicator 

TARGETING 

MONITORING 

Seconds 

Micro-second 

Time  of  end  of  the  engagement 

(impact  time), 

plus  accuracy  indicator 

TARGETING 

MONITORING 

Seconds 

Micro-second 

Point  of  impact 

DAMAGE 

CALCULATION 

Meter 

Sub-decimeter 

Projectile  impact  velocity  (vector), 
plus  accuracy  indicator 

DAMAGE 

CALCULATION 

Meter/sec 

As  required 

Note  that  parameters  such  as  O/C  velocity,  weapon  ID,  ammunition  ID  and  atmospheric  data  are  not  part  of 
the  engagement  dataset.  This  dataset  also  covers  O/C  imitated  missile  engagements  (through  the  parameter 
“time  of  flight”).  The  other  missile  specific  parameters  (“designator”  and  “engagement  validation”)  are  not 
applicable  for  the  O/C  imitated  engagement. 
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O/C  ID 

The  identification  of  the  O/C  that  initiates  the  engagement. 

O/C  Location 

The  three-dimensional  position  of  the  O/C  at  the  start  of  the  engagement. 

Imitated  Party  ID 

The  party  of  the  imitated  shooter.  In  normal  DO  engagements,  the  shooter  ID  will  also  give  access  to  the 
party  and  the  platform  type  of  the  shooter.  This  is  not  the  case  for  an  O/C  engagement,  therefore  the  O/C 
must  specify  this  value  before  the  engagement. 


Imitated  Weapon  Type 

The  weapon  type  of  the  imitated  shooter.  In  normal  DO  engagements,  the  weapon  type  is  implicitly  set  by 
the  shooter,  based  on  the  DO  platform  type  and  settings  by  the  gunner  (e.g.,  a  main  battle  tank  firing  with  the 
main  gun  or  the  coax  machine  gun).  Since  an  O/C  can  simulate  fire  of  any  weapon  type,  the  O/C  must 
specify  this  value  before  the  engagement. 

Imitated  Ammunition  Type 

The  type  of  the  imitated  ammunition.  Since  an  O/C  can  simulate  fire  of  any  weapon  type,  the  O/C  must 
specify  this  value  before  the  engagement.  The  value  of  the  imitated  ammunition  type  should  not  be  in 
conflict  with  the  value  of  the  imitated  weapon  type. 

E.11.2  O/C  Imitated  Energy  Weapon  Engagements 


Table  E-23:  O/C  Imitated  Energy  Weapon  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

O/C  ID 

MONITORING 

ID 

15,000 

- 

O/C  location  (x,  y,  z), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub-decimeter 

Imitated  party  ID 

MONITORING 

Category 

- 

Imitated  weapon  type 

MONITORING 

Category 

- 

Weapon  direction/angle 
(vector),  plus  accuracy 
indicator 

TARGETING 

VERY  HIGH 

Imitated  energy  type 

DAMAGE 

CALCULATION 

Category 

- 

Imitated  energy  level 

DAMAGE 

CALCULATION 

- 

Effect  volume 

DAMAGE 

CALCULATION 

Meter 

Meter 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Activation  time 

TARGETING 

MONITORING 

Seconds 

Second 

Deactivation  time 

TARGETING 

MONITORING 

Seconds 

Second 

Engagement  time 

MONITORING 

Seconds 

Second 

Engagement  duration 

DAMAGE 

CALCULATION 

Seconds 

Second 

Terrain 

TARGETING 

DAMAGE 

CALCULATION 

Meter 

Sub-decimeter 

Atmospheric  data 

TARGETING 

- 

Affected  DO(s)  ID 

DAMAGE 

CALCULATION 

ID 

- 

Affected  DO(s)  location  (x,  y, 
z),  plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub-decimeter 

Affected  DO(s)  velocity 
(vector),  plus  accuracy 
indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

Point  of  impact 

DAMAGE 

CALCULATION 

Meter 

Sub-decimeter 

O/C  ID 

The  identification  of  the  O/C  that  initiates  the  engagement. 

O/C  Location 

The  three-dimensional  position  of  the  O/C  at  the  start  of  the  engagement. 
Imitated  Party  ID 

The  party  of  the  imitated  shooter,  set  by  the  O/C  before  the  engagement. 
Imitated  Weapon  Type 

The  type  of  the  imitated  energy  weapon,  set  by  the  O/C  before  the  engagement. 
Imitated  Energy  Type 

The  type  of  the  emitted  energy,  set  by  the  O/C  before  the  engagement. 

Imitated  Energy  Level 

The  level  of  the  emitted  energy,  set  by  the  O/C  before  the  engagement. 
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E.11.3  Other  O/C  Imitated  Engagements 

An  0/C  can  also  simulate  the  following  engagements: 

•  Repair  engagements; 

•  Medical  engagements;  and 

•  Logistic  engagements. 

The  datasets  for  the  O/C  imitated  engagements  are  exactly  the  same  as  the  datasets  for  the  respective  activities 
of  normal  DOs,  taking  into  account  that  the  “O/C  ID”  and  “O/C  location”  are  replacing  the  respective  “Repair 
DO”,  “Medic  DO”  and  “Supplier  DO”  parameters.  Also  certain  conditions  for  the  engagement  to  take  effect 
do  not  need  to  apply,  such  as  the  O/C  being  and  staying  in  the  direct  vicinity  of  the  affected  DO. 

E.12  INTEGRATION  WITH  THE  AIR  DOMAIN 

E.12.1  Airpower  Example  Situations 

Urban  operations  are  not  exclusively  the  task  for  ground  based  forces,  but  urban  operations  are  generally 
conducted  by  joint  forces,  incorporating  aerial  and  naval  forces. 

Typical  example  situations  from  the  air  domain,  related  to  urban  operations,  have  been  analysed  in  order  to 
derive  any  possible  additional  requirements  regarding  the  UCATT  interfaces  and  the  definition  of  the 
engagement  data.  The  situations  within  an  urban  environment  involving  aerial  entities  can  be  categorised 
into  the  following  tasks: 

•  Close  Air  Support  (CAS):  CAS  is  air  action  by  fixed-wing  and  rotary-wing  aircraft  against  hostile 
targets  that  are  in  close  proximity  to  friendly  forces,  and  requires  detailed  integration  of  each  air 
mission  with  the  fire  and  movement  of  those  forces  (JP3-09-3).  Coordination  is  typically  handled  by 
specialists  such  as  Joint  Fires  Observers,  Joint  Terminal  Attack  Controllers  (JTAC),  and  Forward 
Air  Controllers  (FAC). 

•  Close  Combat  Attack  (CCA):  CCA  is  a  hasty  or  deliberate  attack  by  helicopters  providing  air-to- 
ground  fires  for  friendly  units  engaged  in  close  combat  as  part  of  the  army  combined  arms  team. 
Due  to  the  close  proximity  of  friendly  forces,  detailed  integration  is  required.  Due  to  capabilities  of 
the  aircraft  and  the  enhanced  situational  awareness  of  the  aircrews,  terminal  control  from  ground 
units  or  controllers  is  not  necessary  (US  JP3-09-3). 

•  Airmobile  operation:  An  airmobile  operation  is  an  operation  in  which  combat  forces  and  their 
equipment  manoeuvre  about  the  battlefield  by  aircraft  to  engage  in  ground  combat  (AAP-6,  NATO 
Glossary  of  Term  and  Definitions). 

•  Air  Assault  operation:  An  air  assault  operation  is  an  operation  in  which  integrated  helicopter, 
ground,  combat  support  and  combat  service  support  forces  manoeuvre  and  carry  out  combat,  in  and 
from  the  air. 

•  Air  Mechanised  operation:  An  air  mechanised  operation  is  an  operation  in  which  an  aviation 
force,  heavy  in  armed/attack  helicopters,  conducts  independent  combat  and  attacks  from  the  air 
(AAP-6,  NATO  Glossary  of  Term  and  Definitions). 

•  Para/Airborne  operation:  An  airborne  operation  is  an  operation  involving  the  movement  of 
combat  forces  and  their  logistic  support  into  an  objective  area  by  air.  An  airborne  deployment  is 
carried  out  by  troops  specially  trained  to  carry  out  operations,  either  by  paradrop  or  air  landing, 
following  an  air  movement  (AAP-6,  NATO  Glossary  of  Term  and  Definitions). 

•  Casualty  and  Medical  Evacuation  (CASE VAC,  MEDEVAC):  These  missions  involve  extracting 
wounded  personnel  from  the  battlefield  by  helicopter.  The  medical  helicopter  does  not  engage  other 
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DOs,  but  can  be  engaged  by  other  DOs.  The  medical  helicopter  can  be  escorted  by  armed  helicopters, 
which  can  engage  and  be  engaged  by  other  DOs. 

•  Search  and  Rescue  (SAR)  and  Combat  Search  and  Rescue  (CSAR):  SAR  missions  involve 
extracting  personnel  from  the  battlefield  by  helicopter,  possibly  under  combat  conditions. 
The  helicopters  can  engage  and  be  engaged  by  other  DOs. 

•  Intelligence,  Surveillance,  Target  Acquisition  and  Reconnaissance  (ISTAR):  The  purpose  is  to 
gather  information  from  the  urban  environment.  This  can  be  performed  by  either  armed  or  unarmed 
entities. 

In  reality  a  distinction  is  to  be  made  between  manned  and  unmanned  aerial  systems.  From  the  training 
system  point  of  view,  this  distinction  is  irrelevant.  Unarmed  unmanned  aerial  systems  are  generally  used  for 
gathering  or  relaying  information.  They  do  not  engage  other  DOs,  but  can  be  engaged  by  other  DOs.  Armed 
unmanned  aerial  systems  however,  can  also  serve  as  a  delivery  platform  for  ammunitions  (bombs,  missiles, 
bullets).  Like  manned  aerial  systems  they  can  engage  and  be  engaged  by  other  DOs. 

It  is  recognised  that  aerial  entities  can  engage  each  other,  but  those  related  training  objectives  are  considered 
outside  the  scope  of  urban  operations  live  training  systems. 


E.12.2  Airpower  Requirements 

The  example  situations  within  an  urban  environment  involving  aerial  entities  are  variations  of  either 
engaging  other  entities  or  transportation  of  personnel  and  materiel  to  and  from  the  battlefield.  Based  on  these 
example  situations  the  following  requirements  can  be  derived: 

1)  The  positions  of  the  aerial  entities  need  to  be  tracked,  at  least  for  monitoring  purposes. 

2)  Armed  aerial  entities  must  be  able  to  engage  other  entities.  The  priority  from  an  urban  point  of  view 
is  on  air  to  ground  engagements,  not  on  air  to  air  engagements. 

Aerial  engagements  include: 

a)  Contact  and  proximity  engagements  (covering  direct  fire  weapons  and  bombs). 

b)  Missiles. 

c)  CBRN  areas  (created  by  bombs  or  by  spraying  from  an  aircraft). 

d)  Minefields  (aerial  delivered  mines). 

e)  Energy  weapons. 

3)  Aerial  entities  must  be  able  to  be  engaged  and  change  their  status  accordingly.  The  priority  from  an 
urban  point  is  on  ground  to  air  engagements,  not  on  air  to  air  engagements. 

4)  Personnel  must  be  able  to  mount  and  dismount  (including  rappelling  and  parachuting)  from  aerial 
transport  entities.  Personnel  within  the  aerial  entities  that  can  operate  independently  from  the  aerial 
entity,  should  also  be  modelled  as  DOs.  But  for  example  pilots  need  not  to  be  modelled  as  DOs  and 
can  be  considered  as  integral  part  of  the  aerial  system. 

The  conclusion  is  that  aerial  entities  must  be  considered  as  DOs,  with  all  associated  properties  and 
capabilities.  The  required  interactions  of  aerial  DOs  with  other  DOs  in  the  urban  environment  are  covered  by 
the  datasets  defined  in  the  previous  paragraphs. 


STO-TR-MSG-098 


E  -  43 


ANNEX  E  -  El:  DO  ENGAGEMENT 


organization 


E.13  INTEGRATION  WITH  THE  NAVAL  DOMAIN 
E.13.1  Naval  Use  Cases 

Naval  forces  can  have  an  influence  on  urban  operations  when  naval  entities  operate  close  to  shore,  within 
harbours,  on  rivers  or  on  shore. 

Typical  example  situations  from  the  naval  domain,  related  to  urban  operations,  have  been  analysed  in  order 
to  derive  any  possible  additional  requirements  regarding  the  UCATT  interfaces  and  the  definition  of  the 
engagement  data.  The  following  naval  tasks  and  effects  are  related  to  the  urban  enviromnent: 

•  Naval  fire  support:  Naval  vessels  can  use  their  weapon  systems  to  influence  the  entities  and 
infrastructure  within  the  urban  environment.  This  includes  direct  fires,  indirect  fires  and  missiles. 

•  Amphibious  landing:  This  is  delivering  marine  troops  from  seaborne  vessels  to  shore.  It  can  be  on 
a  large  scale,  using  landing  boats  and/or  amphibious  vehicles,  but  it  also  includes  small  scale  special 
forces  insertions. 

•  Patrolling,  surveillance  and  intelligence  gathering:  Using  seaborne  platforms  close  to  shore  to 
capture  for  example  visual  and  signal  information. 

•  Sea  mines:  Naval  vessels  closing  in  on  shore  can  be  engaged  by  seaborne  contact  or  influence 
mines,  chancing  the  operational  status  and  capabilities  of  those  naval  vessels.  Training  mine 
countermeasures  by  mine  sweeping  or  mine  hunting  vessels  is  considered  outside  the  scope  of  urban 
operations  live  training  systems. 

It  is  recognised  that  naval  entities  can  engage  each  other,  but  those  related  training  objectives  are  considered 
outside  the  scope  of  urban  operations  live  training  systems. 

E.13.2  Naval  Requirements 

The  example  situations  within  an  urban  environment  involving  naval  entities  are  variations  of  either 
engaging  other  entities  or  transportation  of  personnel  and  materiel  to  and  from  the  shore.  Based  on  these 
example  situations  the  following  requirements  can  be  derived: 

1 )  The  positions  of  the  naval  entities  need  to  be  tracked,  at  least  for  monitoring  purposes. 

2)  Armed  naval  entities  must  be  able  to  engage  other  entities.  The  priority  from  an  urban  point  of  view 
is  on  sea  to  shore  engagements,  less  on  sea  to  sea  engagements. 

Naval  engagements  include: 

a)  Contact  and  proximity  engagements  (covering  direct  fire  weapons,  individual  naval  artillery 
shells  and  individual  sea  mines). 

b)  Missiles. 

c)  Sea  mines  (modelled  as  seaborne  minefields). 

d)  Fire  support  areas  (naval  artillery). 

e)  CBRN  areas. 

f)  Energy  weapons. 

3)  Naval  entities  must  be  able  to  be  engaged  and  change  their  status  accordingly.  The  priority  from  an 
urban  point  is  on  ground  to  sea  engagements,  less  on  sea  to  sea  engagements. 

4)  Personnel  must  be  able  to  embark  on  and  debark  from  naval  transport  entities.  Personnel  within  the 
naval  entities  that  can  operate  independently  from  the  naval  entity  (such  as  marine  infantry),  should 
also  be  modelled  as  DOs. 
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These  requirements  apply  to  naval  entities  that  operate  on  the  surface  of  the  water  (surface  ships).  Naval 
entities  that  operate  above  the  surface  are  considered  as  aerial  entities.  Those  requirements  are  covered  by 
Section  D.12. 

Finally,  naval  entities  that  operate  below  the  surface  of  the  water  (submersibles)  are  considered  outside  the 
scope  of  urban  operations  live  training  systems. 

The  conclusion  is  that  (surface)  naval  entities  must  be  considered  as  DOs,  with  all  associated  properties  and 
capabilities.  The  required  interactions  of  (surface)  naval  DOs  with  other  DOs  in  the  urban  environment  are 
covered  by  the  datasets  defined  in  the  previous  paragraphs. 
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F.l  INTRODUCTION 

This  annex  contains  the  definition  of  the  E4  dataset.  E4  reports  on  the  status,  status  changes  and  activities  of 
a  DO. 

The  following  tables  describe  the  content  of  the  E4  interface.  They  contain  one  extra  column,  “priority”, 
to  guide  the  standardisation  effort  with  a  User  point  of  view,  to  be  combined  with  technical  possibilities,  in 
determining  the  extent  of  the  first  version  of  the  UCATT  E4  standard.  The  levels  of  priority  for  the 
parameter  concerning  the  tactical  outcome  of  the  exercise,  analysis  of  the  exercise  or  administrative  purposes 
or  for  future  growth  are  defined  below: 

•  Important  for  the  tactical  outcome  of  the  exercise  =  1 . 

•  Important  for  analysis  of  the  exercise  =  2. 

•  Important  for  administrative  purposes  =  3. 

•  Not  important  for  the  first  version  of  the  UCATT  E4  standard,  but  is  intended  for  future  growth  =  4. 

It  is  recognised  that  the  need  of  a  data  element  to  be  part  of  an  interface  (also)  depends  on  the  technical 
implementation  of  the  training  system  (e.g.,  laser  versus  geo  pairing).  Currently  the  levels  of  priority  are 
based  on  the  importance  of  that  parameter  for  the  training  staff,  not  the  physical  implementation. 

Some  data  can  be  derived  from  other  parameters,  for  example  speed  and  direction  can  be  derived  from  the 
velocity  vector.  If  provided  as  two  separate  parameters,  speed  and  direction  can  have  different  priorities. 
Also,  if  a  higher  level  of  parameter  is  not  present  in  the  dataset,  a  lower  level  parameter  can  become  more 
important. 

F.2  MONITOR  DO  STATUS 

In  the  table  below  the  data  elements  to  monitor  the  status  of  DOs  for  exercise  purposes  are  listed.  In  addition, 
for  each  data  element  a  latency  indication  is  provided.  Latency  is  defined  as  the  delay  between  an  event 
occurring  and  the  data  of  that  event  appearing  in  EXCON.  It  is  a  measure  of  how  critical  the  current  value  of 
the  data  element  is  for  monitoring  and  control  purposes. 

Update  rate  is  the  frequency  of  how  often  information  is  refreshed.  For  simplicity  it  is  assumed  that  the 
update  rate  has  the  same  order  of  magnitude  as  the  latency. 

These  timings  are  divided  into  three  categories: 

•  Real-time,  and  in  effect  this  implies  in  fractions  of  a  second. 

•  Near  real-time,  and  in  effect  implies  in  seconds. 

•  Administrative  time,  is  less  time  critical  and  implies  a  time  longer  than  seconds. 

Table  F-1:  DO  Status  Dataset. 


Data  Element 

Latency 

Priority 

DO  ID,  the  system  identification  of  the  DO 

Near  real-time 

1 

DO  location 

Real-time 

1 

DO  velocity 

Near  real-time 

2 
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Data  Element 

Latency 

Priority 

DO  direction 

Near  real-time 

1 

DO  orientation 

Near  real-time 

1 

DO  articulation  parameters.  An  articulated  part  of  a  DO  is  an 
element  that  can  move  relative  to  the  main  body  of  the  DO 

Near  real-time 

2 

DO  posture,  e.g.  standing,  kneeling,  laying 

Near  real-time 

2 

DO  health  or  operational  status  (‘kill  codes’) 

Real-time 

1 

Equipment  pairing 

Near  real-time 

2 

DO  association 

Near  real-time 

1 

DO  logistic/supplies  state 

Near  real-time 

2 

DO  additional  status  information 

Near  real-time 

2 

It  is  assumed  that  only  the  “DO  ID”  is  part  of  the  E4  dataset  and  that  when  required  the  parameters  “DO  call 
sign”,  “DO  category”,  “DO  type  indication”  and  “DO  force  ID”  are  derived  from  this  parameter. 

The  latency  of  DO  location  and  DO  status  is  low,  because  EXCON  requires  this  information  to  trigger 
certain  events  or  effects  (for  example  to  control  targetry). 

Changes  in  equipment  pairing  must  be  monitored.  This  applies  for  example  to  putting  on/off  body  armour  or 
a  CBRN  mask.  This  includes  also  picking  up  or  putting  down  a  weapon  not  modelled  as  a  DO. 

Changes  in  DO  paring  must  be  monitored.  This  applies  for  example  to  soldiers  mounting  a  vehicle  or 
entering  a  building  and  to  a  soldier  picking  up  or  putting  down  a  weapon  modelled  as  a  DO. 

“DO  additional  status  information”  covers  other  properties  of  a  DO,  typically  properties  of  which  status 
changes  cannot  be  determined  by  engagements,  DO  association  or  equipment  pairing,  but  are  set  and 
changed  by  EXCON  or  O/C  interaction.  An  example  is  “Dug  in”,  indicating  that  a  DO  is  dug  in  and  therefore 
has  a  reduced  probability  of  being  hit  by  for  example  artillery.  Another  example  is  wearing  body  armour, 
which  is  not  sensed  by  the  system,  but  must  be  provided  by  EXCON  or  O/C.  Another  example  of  this  status 
information  is  “Prisoner  status”,  indicating  the  DO  is  taken  prisoner.  This  information  is  important  for 
monitoring  purposes,  because  when  taken  prisoner,  events  happening  to  him  are  in  a  different  context 
(e.g.  being  wounded  or  killed).  Another  example  is  information  resulting  from  engagements,  such  as  detailed 
medical  parameters  not  reflected  in  the  operational  status  (e.g.  heart  rate  or  blood  pressure).  A  third  example 
is  “Reinforced  wall”,  applicable  when  the  occupants  of  a  house  have  strengthened  a  wall  of  the  house, 
decreasing  its  vulnerability  against  certain  ammunitions. 

The  parameter  “DO  additional  status  information”  is  not  further  specified  at  this  moment,  because  it  will 
only  be  part  of  the  highest  level  of  interoperability  of  UCATT  and  contains  elements  that  will  only  be  part  of 
future  systems. 


F.3  MONITOR  DO  SYSTEM  STATE 

System  management  must  be  able  to  monitor  the  following  data: 

•  Technical  status  of  the  training  equipment; 

•  Battery  status; 
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•  BIT  (built  in  test); 

•  Radio  signal  strength  (when  applicable); 

•  Connectivity  of  system  components  (e.g.,  is  the  datalink  operational?);  and 

•  Cheating  signal  (e.g.,  remove  a  cable). 

F.4  DO  STATUS  CHANGE 

The  dataset  of  elements  to  monitor  status  changes  of  DOs  is  shown  in  Table  F-2. 


Table  F-2:  DO  Status  Change  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Affected  DO  ID 

MONITORING 

ID 

- 

1 

Affected  DO  location  (x,  y,  z), 
plus  accuracy  indicator 

MONITORING 

Meter 

World 

coordinate 

Meter 

1 

Affected  DO(s)  velocity, 
plus  accuracy  indicator 

MONITORING 

Meter/sec 

Meter 

1 

Event  time 

MONITORING 

Seconds 

1  second 

1 

Event  type  ID 

MONITORING 

ID 

100 

- 

1 

Event  parameters 

MONITORING 

Number 

10,000 

1 

1 

Causing  DO  ID 

MONITORING 

ID 

15,000 

- 

1 

Event  Time 

The  instance  in  time  when  the  status  change  occurs. 

It  is  possible  that  given  the  combination  of  “Affected  DO  ID”  and  “Interaction  time”  the  properties  of  the 
affected  DO,  such  as  “Affected  DO  location”  and  “Affected  DO  velocity”  can  be  derived  from  other  sources. 

Event  Type  ID 

The  identification  of  the  type  of  event  that  caused  the  status  change.  This  includes: 

•  Contact  and  proximity  engagements. 

•  Missile  engagements. 

•  Area  engagements. 

•  Repair  and  medical  activities. 

•  O/C  interactions. 

•  Time  driven  events,  caused  by  lack  of  activities,  for  example  the  health  of  a  wounded  soldier  who  is 
not  treated  can  degrade  over  time. 

•  Tampering  activities  of  the  trainees. 

Event  Parameters 

The  relevant  parameters  that  are  associated  with  the  “Event  ID”.  These  parameters  are  a  subset  of  the  data 
elements  specified  in  the  respective  engagements. 
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Causing  DO  ID 

The  ID  of  the  DO  that  caused  the  status  change  of  the  affected  DO.  It  can  be  a  “normal”  DO,  an  O/C, 
EXCON  or  it  can  be  not  applicable  if  the  status  change  is  the  result  of  time  driven  processes. 


F.5  ENGAGEMENTS 

F.5.1  Contact  and  Proximity  Engagements 


Table  F-3:  Engagement  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Shooter  ID 

MONITORING 

ID 

100,000 

- 

1 

Shooter  location  (x,  y,  z), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

wide 

Sub-decimeter 

1 

Shooter  velocity  (vector), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

1 

Weapon  type 

TARGETING 

MONITORING 

Category 

- 

1 

Weapon  ID 

ANALYSIS 

ID 

100 

- 

3 

Shooter  weapon  mode 

TARGETING 

MONITORING 

Category 

2 

Weapon  direction/angle 
(vector),  plus  accuracy 
indicator 

TARGETING 

VERY  HIGH 

4 

Ammunition  type 

DAMAGE 

CALCULATION 

MONITORING 

Category 

2 

Fuse  type 

TARGETING 

MONITORING 

Category 

2 

Fuse  settings 

TARGETING 

MONITORING 

2 

Engagement  range 

DAMAGE 

CALCULATION 

MONITORING 

Meter 

Meter 

1 

Detonation  location  (x,  y,  z), 
plus  indicator  of  accuracy 

DAMAGE 

CALCULATION 

MONITORING 

Meter 

Sub-decimeter 

1 

Effect  direction/angle  (vector) 
at  the  moment  of  detonation 

DAMAGE 

CALCULATION 

MONITORING 

HIGH 

2 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Projectile  impact  velocity 
(vector),  plus  accuracy 
indicator 

DAMAGE 

CALCULATION 

Meter/sec 

As  required 

4 

Effect  volume 
(visualise  to  explain  the 
results  to  the  trainees) 

DAMAGE 

CALCULATION 

MONITORING 

Meter 

Meter 

2 

Terrain 

TARGETING 

DAMAGE 

CALCULATION 

Meter 

Sub-decimeter 

4 

Atmospheric  data 

TARGETING 

4 

Affected  DO(s)  ID 

DAMAGE 

CALCULATION 

MONITORING 

ID 

1 

Affected  DO(s)  location 
(x,  y,  z),  plus  accuracy 
indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub-decimeter 

1 

Affected  DO(s)  velocity 
(vector),  plus  accuracy 
indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

1 

Time  of  start  of  the 
engagement  (trigger  time), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Seconds 

Micro-second 

1 

Time  of  end  of  the 
engagement  (impact  time), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Seconds 

Micro-second 

1 

Point  of  impact 

DAMAGE 

CALCULATION 

Meter 

Sub-decimeter 

2 

F.5.2  O/C  Imitated  Contact  and  Proximity  Engagements 

In  addition  to  the  dataset  for  “normal”  contact  and  proximity  engagements,  the  following  parameters  must  be 
implemented  for  engagements  imitated  by  O/Cs. 


Table  F-4:  O/C  Engagement  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

O/C  ID 

MONITORING 

ID 

15,000 

- 

1 

O/C  location  (x,  y,  z), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub¬ 

decimeter 

1 

Imitated  party  ID 

MONITORING 

Category 

- 

1 

Imitated  weapon  type 

MONITORING 

Category 

- 

1 

Imitated  ammunition  type 

DAMAGE 

CALCULATION 

Category 

1 
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F.5.3  Missile  Engagements 

In  addition  to  the  dataset  for  contact  and  proximity  engagements,  the  following  parameters  must  be 
implemented  for  missile  engagements. 


Table  F-5:  Missile  Engagement  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Designator  ID 

TARGETING 

MONITORING 

ID 

15,000 

- 

1 

Designator  location  (x,  y,  z), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub¬ 

decimeter 

1 

Designator  velocity  (vector), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

2 

Duration  of  flight 

TARGETING 

Seconds 

Micro¬ 

seconds 

4 

Engagement  validation 

TARGETING 

YES/NO 

2 

F.6  MINEFIELDS 

When  minefields  are  centrally  managed  by  EXCON,  E4  will  not  be  involved  in  any  data  transfer  regarding 
these  minefields.  Creation  and  deactivation  of  minefields  will  typically  be  reported  to  other  training  systems 
through  E8  and  results  of  engagements  with  minefields  is  sent  through  E3. 

However,  when  a  DO  is  capable  of  creating  and  deactivating  minefields,  (the  results  of)  these  activities  must 
be  reported  to  EXCON.  This  is  done  through  E4.  Also  when  a  DO  is  capable  of  detecting  entering  and 
engaging  with  a  minefield,  E4  is  required. 

F.6.1  Minefield  Creation 


Table  F-6:  Minefield  Creation  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Minefield  ID 

MONITORING 

ID 

- 

1 

Emplacer  ID 

MONITORING 

ID 

15,000 

- 

1 

Mine  IDs  (in  case  of  individual 
virtual  mines) 

3 

Minefield  location 

TARGETING 

Meter 

1,000 

Sub-decimeter 

1 

Ammunition  type(s) 

DAMAGE 

CALCULATION 

Category 

- 

1 

Ammunition  type  density 

TARGETING 

Mines/m2 

0.01 

1 

Activation  time 

TARGETING 

Seconds 

1  second 

1 
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F.6.2  Minefield  Deactivation 


Table  F-7:  Minefield  Deactivation  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Minefield  ID 

MONITORING 

ID 

- 

1 

Deactivation  time 

TARGETING 

Seconds 

1  second 

1 

This  dataset  is  only  relevant  when  a  minefield  is  a  DO  itself.  When  it  only  exists  in  EXCON,  there  is  no  need 
for  E4  interaction.  For  external  communication  E8  would  suffice. 

F.6.3  Minefield  Engagements 

This  dataset  is  only  relevant  when  a  minefield  is  a  DO  itself  and/or  a  DO  can  detect  when  he  enters  a 
minefield. 


Table  F-8:  Minefield  Engagement  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Minefield  ID 

MONITORING 

ID 

- 

1 

Engagement  time 

MONITORING 

Seconds 

1  second 

1 

Terrain 

TARGETING 

DAMAGE 

CALCULATION 

4 

Affected  DO(s)  ID 

DAMAGE 

CALCULATION 

ID 

- 

1 

Affected  DO(s)  location 

DAMAGE 

CALCULATION 

Meter 

- 

1 

F.6.4  Clearing  of  Mines  and  Minefields 

This  dataset  is  only  relevant  for  E4  when  a  DO  is  capable  of  interacting  with  a  minefield,  such  as  clearing 
mines  or  creating  breaching  lanes  through  a  minefield. 


Table  F-9:  Clearing  of  Mines  and  Minefields  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Operator  ID 

TARGETING 

ID 

15,000 

1 

Mine  or  Minefield  ID 

MONITORING 

ID 

- 

1 

Activity 

DAMAGE 

CALCULATION 

Category 

- 

2 

Time  of  start  of  the  engagement 

TARGETING 

MONITORING 

Seconds 

1  second 

1 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Time  of  end  of  the  engagement 

TARGETING 

MONITORING 

Seconds 

1  second 

1 

Breach  lane  location 

TARGETING 

Meter 

1,000 

Sub¬ 

decimeter 

1 

A  DO  can  completely  remove  a  minefield  or  can  create  breaching  lanes,  over  which  a  safe  passage  is 
possible.  The  creation  of  a  breaching  lane  through  a  minefield  requires  an  additional  parameter. 


Breach  Lane  Location 

This  is  a  polygon  describing  a  passage  through  a  minefield.  Depending  on  the  implementation  this  can  be  a 
parameter  of  a  minefield  or  a  separate  object.  Typically  a  breach  lane  starts  and  ends  before  the  borders  of  a 
minefield. 


F.7  FIRE  SUPPORT  TARGET  AREAS 

In  many  current  live  training  systems,  (ground  based)  fire  support  is  not  simulated  by  live  fire  support  DOs, 
but  the  effects  of  fire  support  are  generated,  for  example  by  fire  support  target  areas  created  by  EXCON. 

However,  it  is  envisioned  that  fire  support  entities  can  also  be  part  of  live  training  exercises,  like  for  example 
mortars,  howitzers  and  rocket  launching  systems.  In  that  case,  those  DOs  cannot  engage  their  targets  in  a 
direct  way  and  often  their  targets  are  beyond  their  line  of  sight.  Fire  support  engagements  with  live  fire 
support  DOs  then  require  two  stages.  In  the  first  stage,  the  fire  support  DOs  must  report  their  firing  activities 
to  another  part  of  the  training  system  (typically  EXCON).  These  reports  are  part  of  E4.  In  the  second  stage 
the  training  system  delivers  the  fire  support  engagement  to  the  affected  DO(s).  This  is  part  of  E3. 


Table  F-10:  Fire  Support  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Shooter  ID 

MONITORING 

ID 

100,000 

- 

1 

Shooter  location  (x,  y,  z), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World  wide 

Sub¬ 

decimeter 

1 

Shooter  velocity  (vector), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

1 

Weapon  type 

TARGETING 

MONITORING 

Category 

- 

1 

Weapon  ID 

ANALYSIS 

ID 

100 

- 

3 

Shooter  weapon  mode 

TARGETING 

MONITORING 

Category 

2 

Weapon  direction/angle 
(vector),  plus  accuracy 
indicator 

TARGETING 

VERY  HIGH 

4 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Ammunition  type 
(incl  charge) 

DAMAGE 

CALCULATION 

MONITORING 

Category 

2 

Fuse  type 

TARGETING 

MONITORING 

Category 

2 

Fuse  settings 

TARGETING 

MONITORING 

2 

This  dataset  for  reporting  a  firing  event  by  a  fire  support  DO  is  a  subset  of  the  direct  and  proximity 
engagement  dataset. 

An  important  parameter  is  the  charge  with  which  an  ammunition  is  fired,  because  it  determines  the  ballistic 
trajectory,  and  thus  the  impact  location.  It  is  assumed  that  the  charge  is  part  of  the  “Ammunition  type”, 
otherwise  a  new  parameter  “Charge”  is  required. 


F.8  CBRN  AREAS 

Like  minefields,  when  CBRN  areas  are  centrally  managed  by  EXCON,  E4  will  not  be  involved  in  any  data 
transfer  regarding  these  CBRN  areas.  But  when  a  DO  is  capable  of  creating  and  deactivating  CBRN  areas, 
and  detecting  entering  and  engaging  with  a  CBRN  area,  reporting  (the  results  of)  these  activities  through  E4 
is  required. 

F.8.1  CBRN  Area  Creation 

Table  F-11:  CBRN  Area  Creation  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

CBRN  area  ID 

MONITORING 

ID 

- 

1 

Shooter  ID 

MONITORING 

ID 

15,000 

- 

1 

CBRN  area  location 

TARGETING 

Meter 

Meter 

1 

CBRN  area  shape 

TARGETING 

Meter 

10,000 

Meter 

1 

Agent  type 

DAMAGE 

CALCULATION 

Category 

- 

1 

Agent  density 

DAMAGE 

CALCULATION 

ppm 

1 

1 

Activation  time 

TARGETING 

Seconds 

1  second 

1 
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F.8.2  CBRN  Area  Deactivation 


Table  F-12:  CBRN  Area  Deactivation  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

CBRN  area  ID 

MONITORING 

ID 

- 

1 

Deactivation  time 

TARGETING 

Seconds 

1  second 

1 

F.8.3  CBRN  Area  Engagements 


Table  F-13:  CBRN  Area  Engagement  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

CBRN  area  ID 

MONITORING 

ID 

- 

1 

Engagement  time 

MONITORING 

Seconds 

1  second 

1 

Engagement  duration 

DAMAGE 

CALCULATION 

Seconds 

1  second 

1 

Affected  DO(s)  ID 

DAMAGE 

CALCULATION 

ID 

- 

1 

Affected  DO(s)  location 

DAMAGE 

CALCULATION 

Meter 

- 

1 

F.8.4  CBRN  Decontamination  Area  Creation 


Table  F-14:  CBRN  Decontamination  Area  Creation  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Decontamination  area  ID 

MONITORING 

ID 

- 

1 

Shooter  ID 

MONITORING 

ID 

15,000 

- 

1 

Decontamination  area  location 

TARGETING 

Meter 

1,000 

Meter 

1 

Activation  time 

TARGETING 

Seconds 

1  second 

1 

F.8.5  CBRN  Decontamination  Area  Deactivation 


Table  F-15:  CBRN  Decontamination  Area  Deactivation  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Decontamination  area  ID 

MONITORING 

ID 

- 

1 

Deactivation  time 

TARGETING 

Seconds 

1  second 

1 
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F.8.6  CBRN  Decontamination  Area  Engagements 


Table  F-16:  CBRN  Decontamination  Area  Engagement  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Decontamination  area  ID 

MONITORING 

ID 

- 

1 

Engagement  time 

MONITORING 

Seconds 

1  second 

1 

Engagement  duration 

DAMAGE 

CALCULATION 

Seconds 

1  second 

1 

Affected  DO(s)  ID 

DAMAGE 

CALCULATION 

ID 

- 

1 

Affected  DO(s)  location 

DAMAGE 

CALCULATION 

Meter 

- 

1 

F.9  ENERGY  WEAPONS  ENGAGEMENTS 

F.9.1  Energy  Weapon  Employment 


Table  F-17:  Energy  Weapon  Employment  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Shooter  ID 

MONITORING 

ID 

15,000 

- 

1 

Shooter  location  (x,  y,  z), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub¬ 

decimeter 

1 

Shooter  velocity  (vector), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

1 

Weapon  type 

MONITORING 

Category 

- 

1 

Weapon  ID 

ANALYSIS 

ID 

- 

3 

Shooter  weapon  mode 

TARGETING 

MONITORING 

Category 

2 

Weapon  direction/angle  (vector), 
plus  accuracy  indicator 

TARGETING 

+/-  10% 
compared  to 
actual  weapon 

4 

Energy  type 

DAMAGE 

CALCULATION 

Category 

1 

Energy  level 

DAMAGE 

CALCULATION 

1 

Effect  volume 

(visualise  to  explain  the  results 
to  the  trainees) 

DAMAGE 

CALCULATION 

Meter 

Meter 

2 

Activation  time 

TARGETING 

MONITORING 

Seconds 

1  second 

1 
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Since  many  of  the  parameters  of  employing  an  energy  weapon  can  change  during  the  employment, 
e.g.  shooter  position,  energy  level,  effect  volume  etc.,  these  changes  must  be  reported  when  applicable. 
There  is  not  only  one  start  report  and  one  end  report. 

F.9.2  Energy  Weapon  Engagements 


Table  F-18:  Energy  Weapon  Engagement  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Shooter  ID 

MONITORING 

ID 

15,000 

- 

1 

Shooter  location  (x,  y,  z), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub¬ 

decimeter 

1 

Shooter  velocity  (vector), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter/sec 

Meter 

1 

Weapon  type 

MONITORING 

Category 

- 

1 

Weapon  ID 

ANALYSIS 

ID 

- 

3 

Shooter  weapon  mode 

TARGETING 

MONITORING 

Category 

2 

Weapon  direction/angle 
(vector),  plus  accuracy 
indicator 

TARGETING 

+/- 10% 
compared  to 
actual  weapon 

4 

Energy  type 

DAMAGE 

CALCULATION 

Category 

1 

Energy  level 

DAMAGE 

CALCULATION 

1 

Engagement  time 

MONITORING 

Seconds 

1  second 

1 

Engagement  duration 

DAMAGE 

CALCULATION 

Seconds 

1  second 

1 

Affected  DO(s)  ID 

DAMAGE 

CALCULATION 

ID 

1 

Affected  DO(s)  location  (x,  y, 
z),  plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub¬ 

decimeter 

1 

TARGETING 

MONITORING 

Meter/sec 

Meter 

1 

Point  of  impact 

DAMAGE 

CALCULATION 

Meter 

Sub¬ 

decimeter 

2 

F.9.3  O/C  Imitated  Energy  Weapon  Engagements 

In  addition  to  the  dataset  for  “normal”  energy  weapon  engagements,  the  following  parameters  must  be 
implemented  for  energy  weapon  engagements  imitated  by  O/Cs. 
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Table  F-19:  O/C  Imitated  Energy  Weapon  Engagement  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

O/C  ID 

MONITORING 

ID 

15,000 

- 

1 

O/C  location  (x,  y,  z), 
plus  accuracy  indicator 

TARGETING 

MONITORING 

Meter 

World 

coordinate 

Sub¬ 

decimeter 

1 

Imitated  party  ID 

MONITORING 

Category 

- 

1 

Imitated  weapon  type 

MONITORING 

Category 

- 

1 

Imitated  energy  type 

DAMAGE 

CALCULATION 

Category 

1 

Imitated  energy  level 

DAMAGE 

CALCULATION 

1 

F.10  JAMMERS 
F.10.1  Jammer  Activation 

A  DO  (the  “Carrier”)  must  report  when  he  makes  activate  (switches  on)  or  changes  the  mode  of  a  jammer. 


Table  F-20:  Jammer  Activation  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Carrier  ID 

MONITORING 

ID 

15,000 

- 

1 

Jammer  ID 

MONITORING 

ID 

- 

1 

Jammer  volume 

TARGETING 

Meter 

1,000 

Meter 

1 

Jammer  frequency  list 

DAMAGE 

CALCULATION 

Hz 

- 

1 

Jamming  mode 

TARGETING 

MONITORING 

1 

Activation  time 

TARGETING 

MONITORING 

Seconds 

1  second 

1 

F.10.2  Jammer  Deactivation 

A  DO  (the  “Carrier”)  must  report  when  he  deactivates  (switches  off)  a  jammer. 


Table  F-21:  Jammer  Deactivation  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Carrier  ID 

MONITORING 

ID 

15,000 

- 

1 

Jammer  ID 

MONITORING 

ID 

- 

1 

Deactivation  time 

TARGETING 

Seconds 

1  second 

1 
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F.10.3  Jammer  Engagements 

A  DO  (the  “Affected  DO”)  must  be  reported  when  he  is  influenced  by  a  jammer,  employed  by  another  DO 
(the  “Carrier”). 


Table  F-22:  Jammer  Engagement  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Carrier  ID 

MONITORING 

ID 

15,000 

- 

1 

Jammer  ID 

MONITORING 

ID 

- 

1 

Affected  DO(s)  ID 

DAMAGE 

CALCULATION 

ID 

- 

1 

Affected  DO(s)  location 

DAMAGE 

CALCULATION 

Meter 

- 

1 

F.ll  REPAIR  ACTIVITIES 


Table  F-23:  Repair  Activity  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Repair  DO  ID 

ENGAGING 

MONITORING 

ID 

15,000 

- 

1 

Repair  DO  location  (x,  y,  z), 
plus  accuracy  indicator 

ENGAGING 

MONITORING 

Meter 

World 

coordinate 

Meter 

1 

Repair  activity  ID 

EFFECT 

CALCULATION 

MONITORING 

ID 

100 

1 

Engagement  time 

MONITORING 

Seconds 

1  second 

1 

Repair  duration 

EFFECT 

CALCULATION 

MONITORING 

Number 

43,200 
seconds 
(12  hours) 

Second 

2 

Affected  DO  ID 

ENGAGING 

MONITORING 

ID 

- 

1 

Affected  DO  location  (x,  y,  z), 
plus  accuracy  indicator 

ENGAGING 

MONITORING 

Meter 

World 

coordinate 

Meter 

1 

F.12  MEDICAL  ENGAGEMENTS 


Table  F-24:  Medical  Treatment  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Medic  DO  ID 

ENGAGING 

ID 

15,000 

— 

1 

MONITORING 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Medic  DO  location  (x,  y,  z), 
plus  accuracy  indicator 

ENGAGING 

MONITORING 

Meter 

World 

coordinate 

Meter 

1 

Medical  activity  ID 

EFFECT 

CAECULATION 

MONITORING 

ID 

100 

1 

Engagement  time 

MONITORING 

Seconds 

1  second 

1 

Treatment  duration 

EFFECT 

CALCULATION 

MONITORING 

Number 

43,200 
seconds 
(12  hours) 

Second 

1 

Affected  DO  ID 

ENGAGING 

MONITORING 

ID 

- 

1 

Affected  DO  location  (x,  y,  z), 
plus  accuracy  indicator 

ENGAGING 

MONITORING 

Meter 

World 

coordinate 

Meter 

1 

F.13  LOGISTIC  ENGAGEMENTS 


Table  F-25:  Logistic  Activity  Reporting  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Supplier  DO  ID 

ENGAGING 

MONITORING 

ID 

15,000 

- 

1 

Supplier  DO  location  (x,  y,  z), 
plus  accuracy  indicator 

ENGAGING 

MONITORING 

Meter 

World 

coordinate 

Meter 

1 

Supply  activity  ID 

EFFECT 

CALCULATION 

MONITORING 

ID 

100 

1 

Ammunition  type 

EFFECT 

CALCULATION 

MONITORING 

Category 

1 

Supply  quantity 

EFFECT 

CALCULATION 

MONITORING 

Number 

10,000 

1 

1 

Engagement  time 

MONITORING 

Seconds 

1  second 

1 

Supply  duration 

EFFECT 

CALCULATION 

MONITORING 

Number 

3,600 
(1  hour) 

Second 

2 

Affected  DO  ID 

ENGAGING 

MONITORING 

ID 

- 

1 

Affected  DO  location  (x,  y,  z), 
plus  accuracy  indicator 

ENGAGING 

MONITORING 

Meter 

World 

coordinate 

Meter 

1 
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Annex  G  -  E2:  TRAINING  SYSTEM  STATUS  CHANGE 

This  annex  contains  the  definition  of  the  E2  dataset,  the  interface  that  controls  the  technical  status  of  a 
training  system  and  its  components.  Through  this  interface  it  is  possible  that  a  DO  is  initialised,  reset, 
calibrated  etc.,  and  it  accommodates  the  distribution  of  an  (altered)  terrain  representation  or  damage  models 
for  systems  that  require  this  data  at  decentralised  nodes. 


Table  G-1:  DO  Status  Change. 


Data  Element 

Latency 

Setting  the  DO  ID,  the  system  identification  of  a  DO 

Near  real-time 

Setting  the  equipment  ID  for  components  not  modelled  as  DO 

Near  real-time 

Turning  a  DO  on  and  off 

Near  real-time 

Resetting  a  DO 

Near  real-time 

Requesting  a  BITE  response 

Near  real-time 

Providing  a  DO  with  A-GPS  data  to  enable  it  to  fast  acquire  the  GPS 
signal 

Near  real-time 

Providing  D-GPS  data  to  increase  the  accuracy  of  the  DO  position 

Near  real-time 

Table  G-2:  System  Data  Change. 


Data  Element 

Latency 

Configuration  of  the  system  state 

Near  real-time 

ORB  AT  definitions  (in  part  or  as  a  whole) 

Near  real-time 

Terrain  data  and  damage  model  data.  This  can  be  the  data  itself,  or  a 

Near  real-time 

trigger  to  load/use  the  appropriate  data 

Weather  data,  to  enable  (decentralised)  DOs  to  simulate  behaviour  of 

Near  real-time 

CBRN  areas 
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H.l  INTRODUCTION 

This  annex  contains  the  definition  of  the  E3  interface,  that  sets  the  (simulated)  operational  status  of  a  DO, 
either  as  a  direct  action  of  an  O/C  or  from  EXCON,  to  distribute  the  outcome  of  an  engagement  that  is 
centrally  evaluated  or  to  distribute  characteristics  of  engagement  areas  and  engagement  parameters  in  order 
to  determine  engagements  and/or  outcomes  of  engagements  at  the  DO  level  respectively. 

The  following  tables  describe  the  content  of  the  E3  interface.  They  contain  a  column,  “priority”,  to  guide  the 
standardisation  effort  with  a  user’s  point  of  view,  to  be  combined  with  technical  possibilities,  in  determining 
the  extent  of  the  first  version  of  the  UCATT  E3  standard.  The  levels  of  priority  of  two  types:  need  to  have  or 
nice  to  have: 

•  Need  to  have  -  where  the  parameter  is  required  for  the  tactical  outcome  of  the  exercise  =  1 . 

•  Nice  to  have  -  where  the  parameter  is  required  for  additional  purposes  =  2. 

H.2  O/C  INTERACTIONS 

The  O/C  is  a  member  of  EXCON  who  is  present  in  the  simulated  battlefield  and  therefore  is  also  regarded  as 
a  DO.  The  O/C  interactions  can  be  divided  into  two  categories,  namely  interactions  that  are  specific  to  an 
O/C  (EXCON)  and  that  change  the  status  of  a  DO  directly.  These  interactions  are  part  of  the  external 
interface  E3.  Secondly,  an  O/C  must  be  able  to  execute  or  “imitate”  the  engagements  of  normal  DOs.  These 
imitated  interactions  are  part  of  the  El  interface. 

With  these  interactions  an  O/C  can  control  the  status  of  a  DO,  by  (re)setting  the  value  of  a  particular 
variable.  Generally  this  is  done  as  an  exercise  intervention  outside  the  tactical  training  exercise  context. 
For  example,  to  reset  a  DO  either  because  of  a  malfunction  of  the  training  equipment  or  just  to  let  him 
continue  the  fight  for  training  purposes.  If  the  affected  DO  is  notified  who  caused  the  interaction,  he  will  be 
notified  it  was  an  O/C  or  EXCON  interaction. 

Table  H-1:  O/C  Control  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Causing  DO  ID 

ENGAGING 

MONITORING 

ID 

15,000 

- 

2 

O/C  location  (x,  y,  z), 
plus  accuracy  indicator 

MONITORING 

Meter 

World 

coordinate 

Meter 

1 

Affected  DO  ID 

ENGAGING 

MONITORING 

ID 

- 

1 

Affected  DO  location  (x,  y,  z), 
plus  accuracy  indicator 

MONITORING 

Meter 

World 

coordinate 

Meter 

1 

Interaction  time 

MONITORING 

Seconds 

1  second 

1 

Interaction  type  ID 

EFFECT 

CALCULATION 

MONITORING 

ID 

100 

1 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Variable  to  be  changed 

EFFECT 

CALCULATION 

MONITORING 

1 

New  value 

EFFECT 

CALCULATION 

MONITORING 

Number 

10,000 

1 

1 

Causing  DO  ID 

The  ID  of  the  DO  that  caused  the  status  change  of  the  affected  DO.  It  can  be  a  virtual  DO,  an  O/C  or 
EXCON.  This  parameter  is  listed  as  part  of  this  dataset  to  provide  the  relevant  data  across  training  systems. 
For  example,  when  EXCON  of  system  A  changes  the  status  of  a  DO  of  system  B,  system  B  needs  to  know 
the  source  and  reason  of  the  status  change. 

There  is  an  alternative  to  provide  this  type  on  information  though.  Since  the  source  of  the  status  change  is 
EXCON  of  system  A,  this  information  can  be  provided  to  system  B  through  E8  (EXCON  to  EXCON), 
but  that  is  a  different  solution. 

O/C  Location 

The  location  of  the  O/C,  used  for  monitoring  purposes. 

Affected  DO  ID 

The  ID  of  the  DO  that  is  interacted  with.  In  some  implementations  this  parameter  could  be  omitted,  since  the 
affected  DO  is  the  receiver  of  this  data  message. 

Affected  DO  Location 

The  location  of  the  DO  that  is  interacted  with. 

Interaction  Time 

The  instance  in  time  when  the  interaction  occurs,  used  for  monitoring  purposes. 

Interaction  Type  ID 

This  is  information  that  indicates  to  the  DO  the  reason  for  the  status  change,  for  example  a  reset  by  an  O/C 
or  being  engaged  by  a  weapon  or  ammunition.  This  parameter  can  trigger  a  message  (e.g.,  a  standardised 
audio  sound  such  as  an  explosion  or  text)  on  the  DO  to  inform  the  trainee. 


Variable  to  Be  Changed 

The  identification  of  variable  to  be  changed,  or  a  total  reset  of  all  variables.  Exercise  management  must  be 
able  to  set  or  change  the  following  parameters: 

•  DO  call  sign. 

•  DO  category. 

•  DO  type. 

•  DO  force  ID. 
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•  DO  health  or  operational  status  (“damage  status”). 

•  DO  logistic/supplies  state. 

•  DO  location.  When  a  DO  has  its  own  capabilities  to  determine  its  location,  there  is  generally  no 
need  to  set  its  location  from  EXCON.  Overriding  the  location  of  such  a  DO  could  possibly  result  in 
erroneous  behaviour  of  the  training  system.  However,  when  a  DO  (temporarily)  has  no  access  to  its 
position  (e.g.,  indoor),  EXCON  can  provide  its  position.  Another  example  is  a  mine  or  1ED  device, 
which  has  no  capability  to  determine  its  location  by  itself,  but  when  placed,  is  provided  its  location 
from  EXCON  or  an  O/C. 

•  DO  association.  Normally,  DO  association  must  be  performed  automatically  by  the  training  system. 
However,  if  relevant  DOs  have  no  capability  to  associate  with  each  other  (E9),  e.g.,  a  vehicle 
entering  a  house,  but  the  association  is  important  for  the  outcome  of  the  tactical  exercise  (in  this 
example  the  vehicle  is  protected  by  the  infrastructure  and  it  allows  propagation  of  engagements  and 
of  effects),  then  the  association  can  be  given  by  EXCON  through  E3.  This  can  either  be  an 
automatic  function  (for  example,  when  the  systems  detects  the  locations  of  the  DOs  are  the  same)  or 
can  be  done  manually. 

•  DO  additional  status  information. 

In  addition  to  the  above  defined  capabilities,  the  training  system  must  have  a  broadcast  capability  to  trigger 
recorded  audio  messages  to  all  DO,  e.g.,  for  emergency  situations  to  stop  the  exercise.  The  list  of  recorded 
messages  needs  to  be  standardised. 


New  Value 

The  new  value  to  which  the  specified  variable  will  be  set. 


H.3  ENGAGEMENTS 

First  of  all,  the  E3  datasets  includes  the  complete  El  dataset,  to  enable  that  engagements  can  be  triggered 
centrally  but  that  the  outcome  is  determined  by  the  affected  DOs  (see  Annex  E). 

Secondly,  it  is  possible  through  E3  to  provide  only  the  outcome  of  engagements  to  the  affected  DOs, 
relevant  when  the  outcomes  of  engagements  are  centrally  determined.  These  outcomes  may  for  example 
affect  the  operational  status  of  a  DO  or  it  logistic  supplies. 

Table  H-2:  Control  DO  Variables  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Causing  DO  ID 

MONITORING 

ID 

15,000 

- 

2 

Affected  DO  ID 

DAMAGE 

CALCULATION 

ID 

15,000 

- 

1 

Variable  to  be  changed 

EFFECT 

CALCULATION 

- 

- 

- 

1 

New  value 

EFFECT 

CALCULATION 

Number 

10,000 

1 

1 

Engagement  time 

DAMAGE 

CALCULATION 

Seconds 

Micro-second 

1 
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For  results  of  certain  engagements  more  data  can  be  required  to  provide  to  the  affected  DO  than  just  the  new 
status  and  cause.  Information  regarding  for  example  type  of  ammunition,  distance  and  direction  with  respect 
to  the  DO  can  be  important  to  generate  the  appropriate  messages  or  effects.  Also  the  detonation  location  can 
result  in  different  types  of  explosions,  e.g.  air  burst  versus  ground  explosions,  which  can  be  represented  by 
different  visual  representations  in  the  field,  so  the  trainees  can  learn  from  it  and  take  the  proper  measures. 


Table  H-3:  Control  Contact  and  Proximity  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Causing  DO  ID 

MONITORING 

ID 

15,000 

- 

2 

Affected  DO  ID 

DAMAGE 

CALCULATION 

ID 

15,000 

- 

1 

Variable  to  be  changed 

EFFECT 

CALCULATION 

- 

- 

- 

1 

New  value 

EFFECT 

CALCULATION 

Number 

10,000 

1 

1 

Engagement  time 

DAMAGE 

CALCULATION 

Seconds 

Micro-second 

1 

Ammunition  type 

DAMAGE 

CALCULATION 

MONITORING 

Category 

1 

Engagement  range 

DAMAGE 

CALCULATION 

MONITORING 

Meter 

Meter 

1 

Detonation  location  (x,  y,  z), 
plus  indicator  of  accuracy 

DAMAGE 

CALCULATION 

MONITORING 

Meter 

Sub¬ 

decimeter 

1 

Effect  direction/angle  (vector) 
at  the  moment  of  detonation 

DAMAGE 

CALCULATION 

MONITORING 

HIGH 

1 

H.4  MINEFIELDS 

The  distribution  of  the  characteristics  of  minefields  is  required  to  enable  DOs  to  determine  engagements  and 
resulting  outcomes  locally. 

H.4.1  Minefield  Creation 


Table  H-4:  Minefield  Creation  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Minefield  ID 

MONITORING 

ID 

- 

1 

Mine  IDs  (in  case  of  individual 
virtual  mines) 

2 
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Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Minefield  location 

TARGETING 

Meter 

1,000 

Sub¬ 

decimeter 

1 

Mine  locations  (in  case  of 
individual  virtual  mines) 

TARGETING 

Meter 

1,000 

Sub¬ 

decimeter 

1 

Ammunition  type(s) 

DAMAGE 

CALCULATION 

Category 

- 

1 

Ammunition  type  density 

TARGETING 

Mines/m2 

0.01 

1 

Activation  time 

TARGETING 

Seconds 

1  second 

1 

H.4.2  Minefield  Deactivation 


Table  H-5:  Minefield  Deactivation  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Minefield  ID 

MONITORING 

ID 

- 

1 

Deactivation  time 

TARGETING 

Seconds 

1  second 

1 

H.4.3  Minefield  Engagements 

There  is  no  specific  dataset  required  for  minefield  engagements.  In  case  a  DO  determines  engagements  with 
a  minefield  by  itself,  the  information  is  provided  with  the  “minefield  creation  dataset”.  If  a  DO  is  only 
provided  with  the  mine  or  ammunition  type  that  is  involved  in  the  engagement,  it  is  communicated  through 
the  “control  contact  and  proximity  engagement  dataset”. 

H.4.4  Clearing  of  Mines  and  Minefields 


Table  H-6:  Clearing  of  Mines  and  Minefields  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Minefield  ID 

MONITORING 

ID 

- 

1 

Breach  lane 

TARGETING 

Meter 

1,000 

Sub¬ 

decimeter 

1 

When  a  minefield  is  breached,  one  or  more  lanes  can  be  created  over  which  a  safe  passage  is  possible  and 
these  must  be  known  to  DOs.  This  requires  the  parameter  of  the  breach  lane. 


H.5  FIRE  SUPPORT  TARGET  AREAS 

Information  regarding  (definition  of)  fire  support  target  areas  needs  to  be  provided  through  E3,  when  DOs 
are  responsible  for  determining  engagements  with  these  areas.  When  a  DO  is  only  provided  with  the 
ammunition  type  that  is  involved  in  the  engagement,  it  is  communicated  through  the  “control  contact  and 
proximity  engagement  dataset”. 
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Table  H-7:  Fire  Support  Target  Area  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Fire  support  target  area  location 

TARGETING 

Meter 

Meter 

1 

Fire  support  target  area  shape 

TARGETING 

Meter 

1,000 

Meter 

1 

Ammunition  type 

DAMAGE 

CALCULATION 

Category 

- 

1 

Fuse  type 

TARGETING 

MONITORING 

Category 

1 

Fuse  settings 

TARGETING 

MONITORING 

1 

Number  of  received  salvos 

TARGETING 

Integer 

1 

1 

Ammunition  rounds  per 
received  salvo 

TARGETING 

Rounds/ 

salvo 

1 

1 

Angle  of  impact 

DAMAGE 

CALCULATION 

1 

Activation  time 

TARGETING 

Seconds 

1  second 

1 

Deactivation  time 

TARGETING 

Seconds 

1  second 

1 

H.6  CBRN  AREAS 
H.6.1  CBRN  Area  Creation 


Table  H-8:  CBRN  Area  Creation  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

CBRN  area  ID 

MONITORING 

ID 

- 

1 

Shooter  ID 

MONITORING 

ID 

15,000 

- 

1 

CBRN  area  location 

TARGETING 

Meter 

Meter 

1 

CBRN  area  shape 

TARGETING 

Meter 

10,000 

Meter 

1 

Agent  type 

DAMAGE 

CALCULATION 

Category 

- 

1 

Agent  density 

DAMAGE 

CALCULATION 

ppm 

1 

1 

Activation  time 

TARGETING 

Seconds 

1  second 

1 
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H.6.2  CBRN  Area  Deactivation 


Table  H-9:  CBRN  Area  Deactivation  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

CBRN  area  ID 

MONITORING 

ID 

- 

1 

Deactivation  time 

TARGETING 

Seconds 

1  second 

1 

H.6.3  CBRN  Area  Engagements 

In  case  a  DO  determines  engagements  with  a  CBRN  area  by  itself,  the  information  is  provided  with 
the  “CBRN  area  creation  dataset”.  If  a  DO  must  determine  the  results  of  exposure  to  CBRN  agents, 
this  information  is  passed  through  the  following  dataset,  as  presented  in  Table  H-10. 


Table  H-10:  CBRN  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Affected  DO  ID 

DAMAGE 

CALCULATION 

ID 

15,000 

- 

1 

Agent  type 

DAMAGE 

CALCULATION 

Category 

- 

1 

Agent  density 

DAMAGE 

CALCULATION 

ppm 

1 

1 

Engagement  time 

DAMAGE 

CALCULATION 

Seconds 

1  second 

1 

Engagement  duration 

DAMAGE 

CALCULATION 

Seconds 

1  second 

1 

H.6.4  CBRN  Decontamination  Area  Creation 


Table  H-11:  CBRN  Decontamination  Area  Creation  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Decontamination  area  ID 

MONITORING 

ID 

- 

1 

Shooter  ID 

MONITORING 

ID 

15,000 

- 

1 

Decontamination  area  location 

TARGETING 

Meter 

1,000 

Meter 

1 

Activation  time 

TARGETING 

Seconds 

1  second 

1 
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H.6.5  CBRN  Decontamination  Area  Deactivation 


Table  H-12:  CBRN  Decontamination  Area  Deactivation  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Decontamination  area  ID 

MONITORING 

ID 

- 

1 

Deactivation  time 

TARGETING 

Seconds 

1  second 

1 

H.6.6  CBRN  Decontamination  Area  Engagements 


Table  H-13:  CBRN  Decontamination  Area  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Affected  DO  ID 

DAMAGE 

CALCULATION 

ID 

15,000 

- 

1 

Engagement  time 

DAMAGE 

CALCULATION 

Seconds 

Micro-second 

1 

Engagement  duration 

DAMAGE 

CALCULATION 

Seconds 

1  second 

1 

H.7  ENERGY  WEAPONS  ENGAGEMENTS 

The  following  dataset  is  required  when  EXCON  determines  engagements  with  energy  weapons,  but  the 
affected  DO  is  responsible  for  the  damage  calculation. 


Table  H-14:  Energy  Weapon  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Affected  DO  ID 

DAMAGE 

CALCULATION 

ID 

15,000 

- 

1 

Energy  type 

DAMAGE 

CALCULATION 

Category 

1 

Energy  level 

DAMAGE 

CALCULATION 

1 

Effect  volume 

DAMAGE 

CALCULATION 

Meter 

Meter 

1 

Engagement  time 

DAMAGE 

CALCULATION 

Seconds 

Micro-second 

1 

Engagement  duration 

DAMAGE 

CALCULATION 

Seconds 

1  second 

1 
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H.8  REPAIR  ACTIVITIES 

Typically  when  EXCON  executes  repair  activities,  it  is  sufficient  that  the  affected  DO  is  provided  with  the 
new  status,  as  defined  in  the  basic  E3  dataset  “Control  DO  operational  status  dataset”. 

Elowever,  it  can  be  envisioned  that  either  non-instrumented  mechanics  or  virtual  mechanics  in  the  training 
environment  can  perform  repair  activities.  In  both  cases  the  repair  activity  must  be  initiated  by  EXCON. 


Table  H-15:  Repair  Activity  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Affected  DO  ID 

ENGAGING 

MONITORING 

ID 

15,000 

- 

1 

Repair  activity  ID 

EFFECT 

CALCULATION 

MONITORING 

ID 

100 

1 

Engagement  time 

DAMAGE 

CALCULATION 

Seconds 

1  second 

1 

Repair  duration 

EFFECT 

CALCULATION 

MONITORING 

Number 

43,200 
seconds 
(12  hours) 

Second 

1 

H.9  MEDICAL  ENGAGEMENTS 

Eike  repair  activities  performed  by  EXCON,  it  is  generally  sufficient  that  the  affected  DO  is  provided  with 
the  new  status,  as  defined  in  the  basic  E3  dataset  “Control  DO  operational  status  dataset”.  But  when  non- 
instrumented  or  virtual  medics  can  treat  wounded  personnel,  the  activity  must  be  initiated  by  EXCON 
through  E3. 


Table  H-16:  Medical  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Affected  DO  ID 

ENGAGING 

MONITORING 

ID 

15,000 

- 

1 

Medical  activity  ID 

EFFECT 

CALCULATION 

MONITORING 

ID 

100 

1 

Engagement  time 

DAMAGE 

CALCULATION 

Seconds 

1  second 

1 

Treatment  duration 

EFFECT 

CALCULATION 

MONITORING 

Number 

43,200 
seconds 
(12  hours) 

Second 

1 
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H.10  LOGISTIC  ENGAGEMENTS 

The  dataset  for  logistic  engagements  is  only  required  when  a  logistic  process  must  be  simulated,  that  will  last 
for  a  certain  amount  of  time.  Otherwise  the  basic  E3  dataset  to  change  the  relevant  parameters  is  sufficient. 


Table  H-17:  Logistic  Engagement  Dataset. 


Parameter 

Purpose 

Unit 

Max 

Accuracy 

Prio 

Affected  DO  ID 

ENGAGING 

MONITORING 

ID 

15,000 

- 

1 

Supply  activity  ID 

EFFECT 

CALCULATION 

MONITORING 

ID 

100 

1 

Ammunition  type 

EFFECT 

CALCULATION 

MONITORING 

Category 

1 

Supply  quantity 

EFFECT 

CALCULATION 

MONITORING 

Number 

10,000 

1 

1 

Engagement  time 

MONITORING 

Seconds 

1  second 

1 

Supply  duration 

EFFECT 

CALCULATION 

MONITORING 

Number 

3,600 
(1  hour) 

Second 

2 
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Annex  I  -  EXAMPLES  OF  VIRTUAL,  CONSTRUCTIVE 
AND  LIVE  SIMULATION  INTEGRATION 


This  annex  describes  some  examples  of  virtual  and  constructive  simulation  integration  with  the  live  domain, 
provided  by  nations  participating  in  the  AG. 


1.1  UK  EXAMPLES 

Technical  white  paper  for  NATO  Urban  Combat  Advanced  Training  Technologies  Task  Group 

Matt  Wright,  QinetiQ,  United  Kingdom. 

1.1.1  Better  Training,  Bigger  Audience,  Cheaper 

The  Live  training  domain  is  defined  by  S1SO  as: 

The  domain  where  live  participants  operate  operational  systems  and  platforms  (including  their  full 
range  of  mobility)  in  the  physical  environment. 

By  integrating  synthetic  environments  (as  represented  by  the  Virtual  and  Constructive  domains)  into  the  Live 
domain,  benefits  are  gained  in  terms  of  increased  realism,  broader  training  audience  participation  and  cost 
savings  over  fully  live  training. 

1.1.2  Context 

To  enable  bi-directional  live-virtual-constructive  (LVC)  integration,  information  from  the  Live  domain  needs 
to  be  captured  and  represented  in  Synthetic  Environments.  Live  domain  information  is  currently  captured 
using  GPS,  laser  engagement  and  other  instrumentation  technologies. 

Such  instrumentation  is  becoming  ubiquitous  in  live  training  as  the  technology  price  drops  and  the  capability 
increases.  Advances  driven  by  the  frantic  development  cycle  of  modem  consumer  electronics  are  providing 
benefits  in: 

•  Fast,  efficient  mobile  computer  platforms; 

•  High-capacity  and  infrastructure-less  wireless  data  networks;  and 

•  High  power  density  batteries. 

The  decrease  in  Western  defence  budgets  has  impacted  traditional  live  training  activities.  Live  firing  smart 
munitions  and  operating  complex  modem  vehicles  comes  with  a  price  tag  that  rapidly  makes  live-only 
training  unaffordable.  There  is  a  push  to  implement  synthetic  domain  solutions  in  the  live  to  reduce  costs 
whilst  maintaining  training  effectiveness. 

As  the  need  for  LVC  integration  grows,  so  will  the  proliferation  of  LVC  architectures  and  middle -ware 
solutions.  The  availability  and  variety  of  LVC  integration  solutions  will  reduce  the  entry  costs  traditionally 
associated  with  synthetic-enhanced  live  training.  This  will  make  ‘plug-and-play’  LVC  exercises  a  realistic 
proposition  for  many  Armed  Forces. 

The  following  sections  describe  some  of  the  current  uses  for  LVC  integration  and  an  exploration  of  potential 
future  uses. 
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1.1.3  Current  Uses 

1.1.3. 1  Synthetic  Wrap-Around 

Synthetic  wrap-around  has  been  used  to  enhance  the  ‘deep  battle’  with  constructive  entities.  Management  of 
the  live/synthetic  boundary  is  achieved  by  geographically  isolating  the  live  domain  from  the  synthetic  (see 
Figure  1-1). 


The  synthetic  deep  battle  is  visualised  on  virtual  simulators  (e.g.,  Ground  Moving  Target  Indication  radar, 
tactical  UAVs,  1STAR  sensors).  As  synthetic  entities  move  into  the  live  domain  they  are  ‘replaced’  by  a  live 
instrumented  version  of  the  entity  at  the  live/synthetic  boundary. 

I.1.3.2  Synthetic  ISTAR 

Synthetic  UAV  and  ISTAR  are  used  in  training  where  real  systems  are  expensive  or  not  authorised  to 
operate  in  civilian  airspace. 


Figure  1-2:  Synthetic  UAV. 
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I.1.3.3  Synthetic  Fall  of  Shot 

Synthetic  fall  of  shot  enables  indirect  fires  to  be  visualised  in  the  live  domain.  It  is  common  practice  to 
provide  the  soldier  with  audio  feedback  on  indirect  fire  events;  providing  an  indication  of  direction  and  range 
to  the  effect.  This  is  not  accurate  enough  for  forward  observers  to  call  for  corrected  fires.  By  overlaying  the 
synthetic  environment  effect  on  a  real-world  view,  e.g.  by  injecting  synthetic  imagery  into  binoculars, 
the  forward  observer  can  judge  the  correction  needed  for  the  next  salvo.  This  can  be  considered  as  a  form  of 
Augmented  Reality.  Figure  1-3  shows  a  fall  of  shot  synthetic  indicator,  a  through-sight  Augmented  Reality 
system  used  by  the  British  Army. 


Figure  1-3  :  Fall  of  Shot  Synthetic  Indicator. 


I.1.3.4  Air/Land  Integration 

Virtual  air  simulators  can  be  used  to  deliver  cost  effective  air/land  integration  training  alongside 
instrumented  live  training.  Both  land  and  air  training  audiences  participate  in  a  synchronised  live/synthetic 
environment.  Live  instrumented  entities  are  recreated  in  the  virtual  world  enabling  pilots  to  see  and  engage 
targets  on  the  ground.  By  incorporating  Augmented  Reality  (see  synthetic  fall  of  shot),  land  trainees  can 
visualise  effects  from  the  synthetic  environment. 
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Figure  1-4:  Virtual  Fast  Jet  Cockpit. 


1.1.3. 5  Unmanned  Sensor  Stimulus 

Unmanned  and  autonomous  sensors  can  be  emulated  in  live  training  without  the  need  to  deploy  and  maintain 
operational  sensor  systems.  The  sensors  can  be  modelled  in  a  synthetic  environment  and  stimulated  by 
information  from  training  instrumentation.  Feedback,  alerts  and  warnings  generated  by  the  synthetic  model 
are  fed  into  the  live  training  audience.  Such  operational  systems  could  include  motion  detection  sensors, 
infra-red  tripwire  sensors  and  shot  detection  sensors. 

1.1.4  Future  Uses 

1. 1.4.1  Armour/Infantry  Integration 

To  reduce  track  mileage  costs  in  driving  armoured  vehicles,  it  is  conceivable  that  future  live  infantry 
exercises  will  be  supported  by  virtual  AFVs  (Armoured  Infantry  vehicle  or  main  battle  tank).  The  vehicle 
crew  would  see  a  virtual  representation  of  the  ground  and  be  able  to  engage  targets  for  the  infantry. 
This  would  be  of  particular  use  where  armour  is  providing  depth  fires,  say  in  an  urban  break-in  battle  or 
other  close-quarter  infantry  engagement  where  the  physical  presence  of  the  vehicle  is  not  needed  as  part  of 
battle  inoculation. 
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1.1.4.2  Organic  Land  Air  Defence 

As  airborne  systems  become  cheaper  to  employ,  such  as  micro  UAVs,  missiles  and  helicopters,  the  need  for 
land  forces  to  defend  themselves  from  air  attacks  will  increase.  To  enable  training  in  reaction  to  air  threats, 
virtual  simulations  can  be  used  to  stimulate  live  troops  on  the  ground.  Augmented  reality  woidd  then  be 
needed  to  enable  troops  to  acquire,  target  and  engage  virtual  air  threats. 

1.1.4.3  Embedded  Training  Modes 

Infantry  and  vehicle  sensors  and  targeting  systems  are  becoming  increasingly  sophisticated.  Research  into 
‘hard  kill’  defensive  systems  will  eventually  become  standard  fit  to  armoured  vehicles.  Several  nations  are 
trialling  wearable  shot  detection  systems  that  can  provide  range  and  direction  to  enemy  firing  points. 
At  some  point  in  time,  the  use  of  applique  training  systems  will  need  to  transition  to  embedded  training 
systems.  This  transition  will  present  an  opportunity  to  inject  augmented  reality  threats  into  sighting  systems 
and  to  stimulate  operational  sensors  with  entities  from  synthetic  environments. 

1.1.4.4  Synthetic  Targetry  for  Live  and  Simulated  Firing 

Current  target  technology  uses  acoustic  methods  to  detect  the  path  of  a  round  through  a  target.  The  target 
itself  only  provides  something  for  the  shooter  to  aim  at.  By  removing  the  physical  target  and  replacing  it  with 
either  a  projected  virtual  or  augmented  reality  target,  live  firing  in  the  future  coidd  be  made  more  dynamic 
and  realistic  than  can  be  achieved  with  target  lifters  and  pop-ups. 
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1.2  NLD  EXAMPLE 

Urban  Short  Range  Interaction  (USRI):  an  LVC  solution  to  Urban  Operation  Training 

Muller,  Krijnen,  Visschedijk  (2012),  I/1TSEC  2012. 

USRI  is  one  of  several  cases  and  projects  under  the  umbrella  of  the  TNO’s  (the  Netherlands  Organisation  for 
Applied  Scientific  Research)  LVC  programme.  The  LVC  programme  is  commissioned  by  the  Royal 
Netherlands  Armed  Forces  and  focuses  on  enriching  one  simulation  domain  (live,  virtual  or  constructive) 
with  another.  The  programme  contains  several  cases,  each  with  a  different  angle  and  focus.  The  USRI  case 
focuses  on  enhancing  the  live  environment  with  virtual  entities. 

1.2.1  The  Concept 

The  goal  of  USRI  is  to  present  a  trainee  of  in  a  built  up  area  with  a  virtual  role  player  with  whom  he  can 
interact  in  a  meaningful  and  non-intrusive  way  in  a  live  training  environment  This  means  that  the  trainee  is 
aware  of  the  virtual  role  player,  but  also  the  other  way  around:  the  virtual  role  player  needs  to  know  what  the 
trainee  is  doing  in  order  to  react  appropriately.  The  purpose  of  a  system  based  on  the  USRI  concept  would  be 
to  present  users  with  more  challenging  and  lifelike  targets.  Operators  can  more  easily  train  action- 
intelligence  and  shoot/no-shoot  decision  making,  but  also  be  confronted  with  role  players  that  are  otherwise 
hard  to  present  like  elderly  people,  animals  and  children. 

1.2.2  Proof  of  Concept 

In  2012  a  demonstrator  was  built  using  COTS  available  components.  For  presenting  the  virtual  role  player  to 
the  trainee,  a  standard  beamer  was  used.  For  position  and  skeletal  tracking  of  the  trainee  a  Microsoft  Kinect 
depth-sensing  camera  was  used  together  with  its  free  Software  Development  Kit  to  enhance  interaction 
between  the  virtual  and  the  live  entity,  automated  speech  recognition  (ASR)  was  incorporated  into  the 
system,  for  which  Loquendo  was  used.  ASR  so  far  is  limited  to  short  standard  commands  like  “get  down”  or 
“show  your  hands”.  For  weapon  tracking  a  blue  gun  was  instrumented  with  a  wireless  micro  switch  (trigger) 
and  orientation  sensor.  Finally,  VBS2  with  a  custom  written  plug-in  posed  the  “brain”  of  the  setup, 
translating  sensor  data  into  avatar  behaviour.  During  a  workshop,  organised  to  obtain  user  requirements,  the 
demonstrator  was  introduced  to  several  army,  marine  and  (military)  police  field  operators. 

Figure  1-6  shows  the  USRI  demonstrator  setup,  with  the  beamer  in  the  white  box,  the  Kinect  camera  front 
and  centre  and  the  soldier  with  an  instrumented  blue  gun  and  headphone  with  microphone. 


Figure  1-6:  The  USRI  Demonstrator  Setup. 
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1.2.3  Future  Development 

The  Royal  Netherlands  Army  is  currently  investigating  the  possibility  to  follow  up  on  the  research  done  on 
the  USRi  concept.  The  plan  is  to  use  virtually  presented  role  players  in  the  newly  built  shooting  houses. 
The  use  of  virtual  role  players  is  even  more  advantageous  in  a  live  fire  environment  where  live  role  players 
cannot  be  used  at  all. 


Figure  1-7:  The  Virtual  Role  Player  Reacts  Differently  on  the  User’s  Actions. 


1.2.4  Relation  to  UCATT 

If  systems  like  USRI  were  to  be  used  in  an  integrated  fashion  with  live  training,  the  virtually  presented  role 
players  could  be  considered  as  players  and  given  a  player  ID.  Consequently,  the  need  for  data  logging  and 
monitoring  would  exist  as  it  does  for  live  entities.  EXCON  could  also  control  these  virtual  entities  like  they 
would  with  other  targetry.  During  the  project,  even  the  use  of  the  laser  based  Small  Arms  Transmitter  for  hit- 
point  detection  was  already  examined,  be  it  only  on  the  surface. 
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The  military  subgroup  within  the  AG  has  made  a  quick  scan  of  the  APP-6(C)  (MAY  2011  edition)  to  find 
out  if  there  is  symbology  missing  for  visual  presentation  in  EXCON,  or  MOUT  training  in  general. 
As  a  starting  point  the  subgroup  decided  to  look  at  the  lowest  level  where  MOUT  operations  are  conducted. 
This  Annex  provides  the  preliminary  results,  in  terms  of  missing  symbols  or  modifiers. 

Weapons  (Or  Weapon  Systems) 

•  Shotgun. 

•  Sniper  Rifle  (there  is  a  symbol  for  Single  Shot  Rifle,  but  that  says  nothing  about  the  effective  range  of 
that  rifle). 

•  Pistol. 

•  Anti-structure  rocket  launchers  (e.g.,  PzF-3  Bunkerfaust  or  SMAW  II). 

•  Hand  grenade. 

•  IED  types.  There  is  a  symbol  for  IEDs,  however,  there  is  no  symbol  to  indicate  the  type  of  IED, 
e.g.,  Remotely  Controlled  (Radio,  Command  Wire,  etc.)  or  Victim  Operated  (Pressure  Plate,  Trip  Wire, 
etc.). 

•  Pepper  spray. 

Entities  (Either  Civilian  or  Military) 

•  Prisoner  (not  a  POW,  but  a  civilian  prisoner  taken  under  civilian  law,  by  military  personnel). 

Structures 

•  Nuclear  power  plant. 

•  Most  civilian  structures  or  objects  (e.g.,  train  station,  hospital,  public  transport). 

Non-Play  Entities 

•  O/C. 

•  Fire  marker. 

•  EXCON. 

Control  Measure  Symbols 

•  Secure  object,  enemy  oriented  or  object  oriented,  with  the  addition  of  HVT  (High  Value  Target),  MVT 
orl.VT. 

•  Floor  modifier  (added  to  any  symbol  to  declare  the  specific  floor  in  a  building  on  which  that  entity  or 
unit  resides  or  that  event  or  action  takes  places). 
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RULES  OF  BUSINESS 
(Original  Version  1.0  dated  16  August  2012) 
(Revision  1.2  dated  19  September  2012) 
(Revision  1.3  dated  26  November  2012) 


INTERNATIONAL  MODEL  NORTH  ATLANTIC  TREATY  ORGANIZATION 

Adopted  for  UCATT 


PART  I:  MEETINGS 

Meetings  of  UCATT  (Architecture  and  Standards)  will  be  held  at  a  time  and  place  designated  by  the  Steering 
Group. 


PART  II:  AGENDA 

1)  The  agenda  for  regular  meetings  of  UCATT  shall  be  drawn  up  by  the  Steering  Group  and  communicated 
to  the  members  at  least  two  weeks  prior  to  the  opening  of  the  meetings. 

2)  The  first  item  of  business  for  each  meeting  shall  be  the  approval  of  the  working  agenda  by  a  simple 
majority  vote  of  the  members  present. 

3)  Additional  items  may  be  placed  on  the  agenda,  if  the  UCATT  group  so  decide  by  a  simple  majority  vote 
of  the  members  present. 

PART  III:  REPRESENTATION 

1)  Each  active  member  shall  be  allowed  one  vote.  For  voting  purposes,  members  become  inactive  when 
they  fail  to  attend  two  consecutive  meetings. 

2)  Representation  at  each  meeting  will  be  certified  by  the  Group  Chairperson  and/or  Group  Secretary. 

3)  Members  are  requested  to  participate  to  all  the  meetings,  when  for  reasons  participation  is  not  possible 
they  should  tell  (in  writing)  this  ASAP  to  the  Group  Chairperson  and  Group  Secretary. 

PART  V:  THE  CHAIRPERSON 

1)  The  Group  Chairperson  shall  have  the  responsibility  of  ensuring  the  smooth  operation  of  the  meeting 
through  interpretation  and  enforcement  of  the  Rules.  In  addition  to  exercising  powers  described 
elsewhere  in  the  Rules,  the  Chairperson  shall  declare  the  opening  and  closing  of  each  meeting,  direct 
discussions,  accord  the  right  to  speak  and  announce  decisions.  He/she  shall  rule  on  points  of  order  and, 
subject  to  these  Rules,  shall  have  complete  control  of  the  proceedings  at  any  meeting.  The  Chairperson 
may  suspend  the  rules  for  the  conduct  of  business  when  appropriate  and  for  the  convenience  of  the 
group.  All  votes  on  decisions  within  the  group  must  be  managed  in  accordance  with  the  voting  rules 
which  may  not  be  suspended  by  the  Chairperson. 
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2)  The  decision  of  the  Chairperson  may  be  appealed  by  any  member.  This  motion  is  debatable  by  one 
member  in  favour  and  one  against,  after  which  the  motion  shall  be  put  to  a  vote.  The  Chairperson’s 
decision  will  stand  unless  overruled  by  a  two-thirds  majority  of  eligible  voting  members  present. 


PART  VI:  CONDUCT  OF  BUSINESS 

Business  processes  for  UCATT : 

1)  The  Group  Chairperson  may  declare  the  meeting  open  if  one-third  of  the  members  are  present. 
The  presence  of  a  majority  of  voting  eligible  members  is  required  for  a  decision  to  be  taken  (other 
than  agenda  modifications). 

2)  The  Group  Secretary  will  produce  a  list  of  all  members  that  are  present  at  the  meeting. 

3)  Committees  are  sub-elements  of  the  overall  Group  and  will  not  apply  these  rules  to  their  activities 
other  than  their  responsibility  to  generate  draft  language  and  decision  proposals. 

4)  Voting  on  draft  language  and  decision  proposals  shall  only  occur  at  the  Group  Level  within 
UCATT. 

5)  Decision  motions  (other  than  agenda  modifications)  must  be  developed  by  the  Committees  and 
submitted  in  writing  to  the  Group  Chairperson  and  Secretary.  The  Chairperson  may  take  up  to 
twelve  (12)  hours  to  review  the  motion  before  presenting  it  to  the  overall  membership  for  review. 

6)  Decision  motions  must  be  presented  to  the  voting  members  at  least  12  hours  before  the  vote  is  called 
to  allow  review  and  consultations. 

7)  Amendments  may  be  proposed  by  any  member  during  discussion  and  must  be  presented  to  the 
Group  Chairman  in  writing  or  through  dictation  (word  for  word)  during  live  discussion. 

8)  The  following  motions  shall  be  utilised  to  facilitate  decision  making  during  the  meeting: 

a)  Decision  Proposal  (Motion) 

To  introduce  a  new  piece  of  business  or  propose  a  new  decision  or  action,  a  motion  must  be 

made  by  the  Committee  Chair/Secretary  (“1  move  that . ”).  A  second  motion  must  then  also  be 

made  (raise  your  hand  and  say,  “1  second  it.”)  After  debate  &  discussion  the  group  then  votes  on 
the  motion.  Administrative  motions  regarding  business  proceedings  or  deliberations  regarding  a 
pending  decision  or  action  may  be  made  by  any  active  member.  A  second  motion  may  be 
required  as  appropriate  along  with  additional  discussion.  All  administrative  motions  must  be 
resolved  prior  to  voting  on  affected  decision  or  action  motions. 

Note:  If  more  than  one  motion  is  proposed,  the  most  recent  takes  precedence  over  the  ones 
preceding  it. 

b)  Point  of  Order 

During  the  discussion  of  any  matter,  a  member  may  raise  a  Point  of  Order,  and  the  point  of 
order  shall  be  immediately  decided  by  the  Chairperson  in  accordance  with  the  Rules  of 
Procedure.  A  Point  of  Order  may  relate  to  the  maintenance  of  order,  the  observance  of  Rules, 
or  the  way  in  which  the  presiding  officers  exercise  the  powers  conferred  upon  them. 
Am  argument  for  or  against  the  pending  question  shall  not  be  recognised  as  a  valid  point  of 
order.  A  point  of  order  is  the  only  circumstance  under  which  a  speaker  may  be  interrupted. 
The  Chairperson  may  refuse  to  recognise  points  of  order  if  it  is  their  judgment  that  the  member 
has  not  maintained  the  restraint  and  decorum  which  should  govern  the  use  of  such  a  right,  or  if 
in  their  judgment  the  point  is  clearly  dilatory  in  nature. 
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c)  Point  of  Information 

A  Point  of  Information  is  raised  to  the  Chairperson  if  a  member  wishes  to  obtain  a  clarification 
of  procedure  or  a  statement  of  the  matters  before  the  body.  Members  may  not  interrupt  a 
speaker  on  a  Point  of  Information. 

d)  Point  of  Inquiry 

A  member  requesting  clarification  or  additional  information  will  raise  a  Point  of  Inquiry. 
A  Point  of  Inquiry  may  be  used  to  question  a  speaker  only  after  he/she  has  finished  their 
remarks  and  may  not  interrupt  any  speaker.  A  questioner  will  address  the  Point  of  Inquiry  to  the 
Chairperson,  who  will  then  ask  the  speaker  if  they  wish  to  yield. 

e)  To  Suspend  the  Meeting 

During  the  discussion  of  a  matter,  a  member  may  move  for  the  Suspension  of  the  meeting. 
Should  the  Chairperson  entertain  it,  it  shall  immediately  be  put  to  a  vote.  The  suspension  of  a 
meeting  requires  a  simple  majority  of  the  members  present  and  voting. 

f)  To  Adjourn  the  Meeting 

At  the  conclusion  of  business  defined  in  the  approved  agenda,  a  member  may  move  for  the 
Adjournment  of  the  meeting  until  the  next  scheduled  date.  This  motion  is  only  in  order  for  the 
full  membership  and  requires  a  second  and  a  two-thirds  majority. 

g)  To  Suspend  Debate  on  the  Item  under  Discussion 

During  the  discussion  of  any  matter,  a  member  may  move  to  Suspend  debate  on  the  item  under 
discussion.  Two  representatives  may  speak  in  favor  of  the  motion  and  two  against  the  motion, 
after  which  the  motion  shall  immediately  be  put  to  a  vote.  This  motion  requires  a  two-thirds 
majority  to  pass. 

h)  To  Close  Debate  on  the  Item  under  Discussion 

A  member  may  move  for  Closure  of  debate  on  the  item  under  discussion;  whether  or  not  any 
other  member  has  signified  his/her  desire  to  speak.  Two  members  may  speak  in  favor  of  the 
motion  and  two  against,  after  which  time  the  motion  shall  be  put  to  an  immediate  vote. 
This  motion  requires  a  two-thirds  majority  vote  to  pass. 

i)  To  Postpone  Indefinitely 

This  tactic  is  used  to  kill  a  motion.  When  passed,  the  motion  cannot  be  reintroduced  at  that 
meeting.  It  may  be  brought  up  again  at  a  later  date.  This  is  made  as  a  motion  (“I  move  to 
postpone  indefinitely...”).  A  second  is  required.  A  majority  vote  is  required  to  postpone  the 
motion  under  consideration. 

j)  To  Change  the  Order  of  Consideration  of  Agenda  Items 

Agenda  items  will  be  considered  in  the  order  in  which  they  appear  on  the  agenda,  unless  that 
order  is  altered  by  the  passage  of  a  motion  To  Change  the  Order  of  Consideration  of  Agenda 
Items.  This  motion  is  only  in  order  during  the  first  session  of  the  conference.  Once  the  agenda 
has  been  set,  it  may  not  be  changed  unless  the  group  is  tasked  with  a  crisis  by  the  Steering 
Committee.  A  majority  vote  is  needed  for  passage. 

k)  To  Limit  Debate  on  the  Item  under  Discussion 

When  discussing  an  item  on  the  agenda,  a  member  may  move  to  Limit  Debate.  The  purpose  of 
this  motion  is  to  focus  the  committee’s  attention  on  the  topic  or  individual  draft  resolution  or 
amendment.  Once  this  motion  has  passed,  debate  is  limited  to  introducing  and  discussing  any 
draft  language  under  that  topic.  A  member  may  also  limit  debate  to  draft  language  or  an 
amendment,  meaning  all  discussion  must  be  relevant  to  the  document  at  hand.  Once  limited, 
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debate  on  a  topic  or  document  can  be  suspended  or  closed.  This  motion  requires  a  second  and  a 
simple  majority. 

l)  To  Divide  the  Question 

In  the  group,  a  member  may  move  to  Divide  the  Question,  so  that  parts  of  draft  language  or  an 
amendment  could  be  voted  on  separately.  If  objection  is  made  to  the  request  for  division, 
the  motion  shall  be  voted  upon,  requiring  a  simple  majority  to  pass.  Permission  to  speak  on  the 
motion  shall  be  accorded  to  two  speakers  in  favour  and  two  against.  If  the  motion  for  division  is 
carried,  those  parts  of  the  proposal  shall  then  be  put  to  a  vote  as  a  whole.  If  all  operative  parts  of 
the  proposal  or  of  the  amendment  have  been  rejected,  the  proposal  or  the  amendment  shall  be 
considered  to  have  been  rejected  as  a  whole. 

m)  To  Amend  the  Item  under  Discussion 

An  Amendment  is  that  which  adds  to,  deletes,  or  alters  part  of  the  Draft  Language.  Amendments 
must  be  submitted  in  writing  (or  dictated  word  for  word  during  live  forum)  to  the  Chairperson 
during  the  discussion  of  a  Draft  Language  and  must  receive  their  approval.  The  Chairperson 
may,  at  their  discretion,  limit  the  number  of  amendments  or  request  members  to  combine  similar 
amendments.  Amendments  shall  be  numbered  in  the  order  in  which  they  are  received.  Once  the 
Amendment  is  introduced,  all  sponsors  of  the  draft  language  to  which  the  Amendment  pertains 
must  be  asked  if  the  Amendment  is  Friendly  or  Unfriendly.  If  the  Amendment  is  deemed 
Friendly  by  all  Sponsors,  then  it  is  automatically  adopted  into  the  Draft  Language.  If  the 
Amendment  is  deemed  Unfriendly  by  any  of  the  Sponsors,  then  it  is  dismissed  and  voted  upon 
by  the  Group.  The  Group  may  limit  debate  to  any  dismissed  Amendment  and  at  the  closure  of 
debate  on  the  Amendment,  the  Amendment  will  be  voted  upon  by  the  Group.  Regardless  of 
limitation,  all  dismissed  Amendments  must  be  voted  upon  by  the  Group  after  the  closure  of 
debate  on  relevant  draft  language. 

This  is  the  process  used  to  change  a  motion  under  consideration.  Perhaps  you  like  the  idea 
proposed  but  not  exactly  as  offered.  Raise  your  hand  and  make  the  following  motion:  “I  move  to 
amend  the  motion  on  the  floor.”  This  also  requires  a  second.  After  the  motion  to  amend  is 
seconded,  a  majority  vote  is  needed  to  decide  whether  the  amendment  is  accepted.  Then  a  vote 
is  taken  on  the  amended  motion.  In  some  organisations,  a  “friendly  amendment”  is  made.  If  the 
person  who  made  the  original  motion  agrees  with  the  suggested  changes,  the  amended  motion 
may  be  voted  on  without  a  separate  vote  to  approve  the  amendment. 

n)  To  Reconsider 

When  a  proposal  has  been  adopted  or  rejected  it  may  not  be  considered  at  the  same  session  but 
may  be  introduced  at  the  next  meeting  and  must  be  approved  by  a  two-thirds  majority. 
Permission  to  speak  on  a  Motion  to  Reconsider  will  be  accorded  to  speakers  opposing  and 
favouring  the  motion. 

o)  Right  of  Reply 

The  Chairperson  may  accord  a  Right  of  Reply  in  the  case  of  grave  personal  insult  and  injury. 
The  offence  to  which  the  member  is  responding  must  occur  within  formal  debate.  The  right  of 
reply  must  be  submitted  in  writing  to  the  Chairperson.  Upon  the  Chairperson’s  approval, 
the  member  may  move  for  a  right  of  reply.  The  time  granted  for  a  right  of  reply  is  at  the 
Chairperson’s  discretion.  There  may  not  be  a  right  of  reply  in  response  to  another  member’s 
right  of  reply. 

p)  Call  the  Question 

To  end  a  debate  immediately,  any  member,  when  mandatory  debate  has  been  completed 
regarding  a  specific  draft  language  or  decision  proposal,  may  Call  the  Question  which  when 
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seconded  serves  to  direct  the  Chairperson  to  discontinue  discussion  and  poll  the  voting 
membership  for  a  vote  on  the  issue  at  hand.  A  two-thirds  vote  is  required  for  passage.  If  it  is 
passed,  the  motion  on  the  floor  is  voted  on  immediately. 

q)  Commit 

This  is  used  to  place  a  motion  in  committee.  It  requires  a  second.  A  majority  vote  must  rule  to 
carry  it.  At  the  next  meeting  the  committee  is  required  to  prepare  a  report  on  the  motion 
committed.  If  an  appropriate  committee  exists,  the  motion  goes  to  that  committee.  If  not,  a  new 
committee  is  established. 

r)  Table 

To  Table  a  discussion  is  to  lay  aside  the  business  at  hand  in  such  a  manner  that  it  will  be 
considered  later  in  the  meeting  or  at  another  time  (“I  make  a  motion  to  table  this  discussion  until 
the  next  meeting.  In  the  meantime,  we  will  get  more  information  so  we  can  better  discuss  the 
issue.”)  A  second  is  needed  and  a  majority  vote  required  to  table  the  item  being  discussed. 

PART  VII:  VOTING 

1)  Each  active  member  within  UCATT  shall  be  accorded  one  vote  in  the  Group. 

2)  Voting  must  be  either  in  person  or  by  proxy.  If  by  proxy,  the  voting  member  must  designate  to  the 
Chairperson  and  Secretary  their  proxy  from  the  list  of  existing  eligible  UCATT  voting  members. 
The  proxy  vote  may  be  cast  only  on  decision  motions  formally  announced  in  a  previous  UCATT 
meeting. 

3)  All  decision  proposals  of  the  Group  must  be  approved  by  a  simple  majority  of  all  voting  members 
present,  but  with  the  realisation  that  unanimous  consent  is  desirable. 

4)  Administrative  motions  shall  be  voted  on  in  accordance  with  the  relevant  parts  of  the  Rules. 

5)  Immediately  prior  to  a  vote,  the  Chairperson  shall  describe  to  the  body  the  item  to  be  voted  on,  and  shall 
explain  the  consequences  of  a  “yes”  or  a  “no”  vote.  Voting  shall  begin  upon  the  Chairperson’s 
declaration  “the  question  has  been  called,”  and  end  when  the  results  of  the  vote  are  announced.  Once  in 
voting  procedure,  no  member  shall  interrupt  the  voting  except  on  a  point  of  order  concerning  the  actual 
conduct  of  the  vote.  Following  Closure  of  Debate,  and  prior  to  entering  voting  procedure,  the 
Chairperson  shall  pause  briefly  to  allow  members  the  opportunity  to  make  any  relevant  motions. 

6)  Voting  shall  normally  be  carried  out  by  raising  of  hands,  unless  a  representative  requests  a  Roll  Call 
Vote  where  individual  voters  are  called  by  name  and  respond  with  “Aye”  or  “No”  verbally. 

7)  If  hands  are  not  raised  indicating  a  No  vote,  then  the  Group  Secretary  shall  record  the  vote  as  unanimous 
in  the  affirmative. 

8)  The  term  No  with  rights  may  be  used  by  members  wishing  to  explain  their  vote  after  voting  has 
concluded.  This  right  may  be  limited  by  the  Chairperson. 

9)  A  member  may  record  a  formal  Reservation  if  a  particular  part  of  a  proposal  is  partially  unacceptable  to 
him/her.  This  reservation  is  raised  at  the  time  of  voting  and  will  be  formally  recorded  on  the  proposal  in 
question. 


PART  VIII:  GENERAL 

1)  The  official  language  of  the  sessions  is  English. 
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2)  Members  are  expected  to  dress  in  UCATT  casual  for  the  duration  of  the  meetings. 

3)  The  NATO  UCATT  Task  Group  Chair  with  the  lower  assigned  MSG  #  will  act  as  the  overall  Group 
Chairperson  when  multiple  Task  Groups  are  collaborating  on  the  UCATT  program. 

4)  The  UCATT  Group  will  consist  of  any  and  all  NATO  level  Task  Groups  chartered  to  address  the 
interoperability  of  instrumentation  and  operating  with  the  UCATT  name. 

Voted  on  and  unanimously  approved  by  the  UCATT  membership  in  attendance  -  19  September  2012. 


Armin  Thinnes 
Chairman 

NATO  UCATT  MSG-098 
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L.l  PARTICIPATING  NATIONS 

Individual  Nations  that  participated  (representatives  came  from  Government  and/or  Industry)  are: 


•  Austria  AUT 

•  Canada  CAN 

•  Finland  FIN 

•  France  FRA 

•  Germany  DEU 

•  Netherlands  NLD 

•  Spain  ESP 

•  Sweden  SWE 

•  Switzerland  CHE 

•  Turkey  TUR 

•  United  Kingdom  GBR 

•  United  States  of  America  USA 


L.2  STEERING  GROUP  MEMBERS 

Chairman:  Mr.  Armin  Thinnes,  German  Federal  Office  of  Bundeswehr  Equipment,  Information 
Technology  and  In-Service  Support,  GOV,  DEU. 

Secretary:  Mr.  Osmo  Forsten,  Finnish  Defence  University,  GOV,  FIN;  ad  interim:  Mr.  Jan  Vermeulen, 
Defence  Materiel  Organisation,  GOV,  NLD. 

Other  Steering  Group  Members:  Mr.  Gary  Washam,  CUBIC,  IND,  USA;  Maj.  Johnny  Gullstrand,  GOV, 
SWE;  Mr.  Rudi  Gouweleeuw,  GOV,  NLD. 

L.3  PARTICIPANTS 

Participants  of  MSG-098  and  MSG-099  are  listed  in  the  table  below. 


Table  L-1:  UCATT-3  MSG-098  and  MSG-099  Participants. 


Nation 

Rank/Title 

Name 

Department/Company 

Timeframe* 

MSG 

SWE 

Mr. 

Alexanderson,  Magnus 

SAAB  AB 

2012-2015  (8) 

99 

USA 

Mr. 

Blahnik,  Steve 

Cubic  Global  Defense 

2012-2015  (8) 

99 

USA 

Mr. 

Campos,  Jesse 

PEOSTRI 

2011  -2015  (9) 

98 

GBR 

Mr. 

Chamberlain,  Mark 

Defence  Equipment  and 
Support  UK  MoD 

2011  -2015  (11) 

98 
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Nation 

Rank/Title 

Name 

Department/Company 

Timeframe* 

MSG 

DEU 

Mr. 

Christians,  Ernst 

Rheinmetall  Defence 
Electronics  GmbH 

2014-2015  (2) 

98 

TUR 

Mr. 

Colakoglu,  Cagatayhan 

Aselsan  Inc. 

2011  (1) 

98 

FRA 

Mr-. 

Coriat,  Michel 

Thales  Training  & 
Simulation 

2011  -2014(7) 

98 

NLD 

Capt 

Cruiming,  Sander 

Royal  Netherlands  Army 

2011  -2015  (12) 

98 

USA 

Mr-. 

Dasher,  Mark 

PEOSTRI 

2011  (1) 

98 

FRA 

Mr-. 

Desfachelles,  Thomas 

Direction  Generate  de 
l’Armement 

2011  -2014(7) 

98 

FRA 

Mr. 

Desruelles,  Philippe 

Airbus  Defence  &  Space 

2011  -2014(5) 

98 

DEU 

Dr. 

Dobrindt,  Uwe 

Rheinmetall  Defence 
Electronics  GmbH 

2014-2015  (3) 

99 

DEU 

Mr. 

Eisenhauer,  Joachim 

Rheinmetall  Defence 
Electronics  GmbH 

2011  -2015  (8) 

99 

CHE 

Ret  Col 

Fenner,  Max 

RUAG  Defence 

2012-2015  (10) 

98 

CAN 

Mr. 

Forgues,  Stephane 

Department  of  National 
Defense 

2013  (2) 

98 

FIN 

Mr-. 

Forsten,  Osmo 

Finnish  Defence  Forces 

2011  (2) 

98 

NLD 

Mr. 

Gouweleeuw,  Rudi 

Netherlands  Organisation 
for  Applied  Scientific 
Research  TNO 

2011  -2015  (12) 

98 

SWE 

Maj 

Gullstrand,  Johnny 

Swedish  Armed  Forces 

2011  -2015  (12) 

98 

AUT 

Lt  Col 

Habitzl,  Wolfgang 

Austrian  Armed  Forces 

2015(1) 

98 

NZL 

Mr-. 

Handley,  Paul 

Cubic  Global  Defense 

2012-2013  (3) 

99 

SWE 

Mr-. 

Holmquist,  Anders 

SAAB  AB 

2011  (1) 

99 

AUT 

Lt  Col 

Horak,  Robert 

Austrian  Armed  Forces 

2014(2) 

98 

SWE 

Maj 

Karlsson,  Roger 

Swedish  Armed  Forces 

2012-2013  (4) 

98 

CHE 

Lt  Col 

Lerch,  Rolf 

Swiss  Armed  Forces 

2011  -2012  (4) 

98 

SWE 

Mr. 

Lindstrom,  Anders 

SAAB  AB 

2011  -2014(10) 

99 

DEU 

Lt  Col 

Makowski,  Peter 

German  Armed  Forces 

2011  -2015  (10) 

98 

SWE 

Mr. 

Martinsen,  Staffan 

Swedish  Defence 

Materiel  Administration 
/FMV 

2013-2015  (5) 

98 

DEU 

Mr-. 

Neugebauer,  Holger 

WTD91,  German  Armed 
Forces 

2014-2015  (3) 

99 

SWE 

Mr-. 

Nyfelt,  Leif 

NSC 

2011  (1) 

99 
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Department/Company 

Timeframe* 

MSG 

ESP 

Maj 

Pinedo,  Carlos 

Belinchon 

Spanish  Armed  Forces 

2011  (2) 

98 

USA 

Mr. 

Platt,  Kyle 

PEOSTR1 

2012(1) 

99 

DEU 

Mrs. 

Ross,  Bettina 

Drew  Defense  (formerly 
Chemring  Deutschland) 

2012  (2) 

99 

DEU 

Mr. 

Thinnes,  Armin 

German  Federal  Office  of 
Bundeswehr  Equipment, 
Information  Technology 
and  In-Service  Support 

2011  -2015  (12) 

98/99 

USA 

Mr. 

Tucker,  Frank 

PEOSTR1 

2012(1) 

98 

NLD 

Mr. 

Vermeulen,  Jan 

Defence  Materiel 
Organisation 

2011  -2015  (11) 

98/99 

FRA 

Mr. 

Vinatier,  Thierry 

Airbus  Group  GDI 
Simulation 

2011  -2015  (11) 

99 

SWE 

Mr. 

von  Rothstein,  Niclas 

Swedish  Defence 

Materiel  Administration 
/FMV 

2011  (1) 

98 

USA 

Mr. 

Washam,  Gary 

CUBIC  Global  Defense 

2011  -2014(7) 

99 

DEU 

Mr. 

Wittwer,  Ingo 

RUAG  Defence 
Deutschland  GmbFI 

2011  -2015  (12) 

99 

GBR 

Mr. 

Wright,  Matthew 

QinetiQ  Pic 

2012(1) 

98 

TUR 

Mr. 

Zafer,  Y ahsi 

Aselsan  Inc. 

2011  (1) 

98 

FRA 

Ms. 

Zundel,  Catherine 

Direction  Generate  de 
l’Armement 

2015 (1) 

98 

*  Number  of  Meetings  attended  shown  in  brackets 


L.4  MEETING  LOCATIONS 


Table  L-2:  UCATT  MSG-098  Meeting  Locations. 


2011 

2012 

2013 

2014 

2015 

Warminster  (GBR) 

Rome  (ITA) 

San  Diego  (USA) 

Vienna  (AUT) 

Granna  (SWE) 

Paris  (FRA) 

Koblenz  (DEU) 

Amersfoort  (NLD) 

Orlando  (USA) 

Orlando  (USA) 

Orlando  (USA) 

Orlando  (USA) 
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